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ABSTRACT 


This  handbook  of  Air  Force  automatic  data  processing  experience 
is  a  pilot  version  of  one  to  be  produced  in  the  next  phase  of  the  project. 
The  ADP  experience  data  was  collected  by  interview  on  18  Air  Force 
ADP  systems;  the  handbook  produced  during  the  next  phase  of  the  proj¬ 
ect  will  be  updated  from  experience  periodically  reported  to  Headquar¬ 
ters,  USAF,  from  some  200  ADP  systems.  The  purpose  of  the  pilot 
version  is  to  acquaint  Air  Force  personnel  with  the  concept  of  using 
highly  organized,  summarized,  and  retrievable  ADP  experience  in  judg- 
ing  proposals  for  new  automation.  The  pilot  version  of  the  handbook 
contains  data  collected  after  the  fact  from  only  18  ADP  systems,  and 
hence  the  handbook  has  limited  usefulness  for  actual  evaluation  of  ADPS 
proposals.  It  does,  however,  contain  cost  estimation  equations  and  nar¬ 
rative  experience  that  will  be  useful  until  the  200  system  handbook  can 
be  produced  in  Phase  III. 

Experience  relevant  to  a  proposed  ADPS  is  retrieved  from  the  hand¬ 
book  via  information  extracted  from  the  proposal.  The  extracted  infor¬ 
mation  consists  of  quantitative  workload  descriptors  of  the  proposed 
ADPS  (e.  g.  ,  number  of  input  data  fields  and  number  of  output  formats) 
and  certain  qualitative  descriptors  (e.  g.  ,  centralized  or  decentralized 
operations  and  presence  or  absence  of  direct  access  storage) .  The  quan¬ 
titative  workload  descriptors  are  used  with  cost  estimation  iso-graphs 
in  the  handbook  to  predict  costs,  so  that  proposed  cost  factors  (e.  g.  , 
man-months  of  development  effort  and  dollars  per  month  of  hardware 
cost  for  application  production)  may  be  compared  with  Air  Force  ex¬ 
perience.  Both  quantitative  and  qualitative  descriptors  are  used  to  re¬ 
trieve  relevant  information  from  the  18  system  descriptions  found  in  the 
handbook.  The  retrieved  experience  will  be  used  to  check  consistency 
and  to  uncover  potential  problems  of  the  proposed  ADPS  that  may  be  en¬ 
countered  during  system  development  and  operation. 

A  primer  on  the  use  of  this  handbook  applied  to  a  hypothetical  ADPS 
proposal  is  published  separately  as  ESD-TR-66-672.  A  final  report  cov¬ 
ering  activities  and  conclusions  of  the  project  is  also  published  sepa¬ 
rately  as  ESD-TR-66-671 . 
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I.  USE  OF  EXPERIENCE  HANDBOOK 


The  Experience  Handbook  is  used  to  evaluate  a  proposed  ADPS  in 
two  major  steps.  The  first  step  involves  the  comparison  of  proposed 
cost  factors  such  as  man-months  of  development  effort  with  estimated 
cost  factors  obtained  through  use  of  cost  estimation  iso-graphs.  These 
iso-graphs  are  graphical  representations  of  cost  estimation  equations 
derived  from  sampled  data  on  18  Air  Force  ADP  systems.  Subsection 
I.  A.  describes  the  use  of  these  iso-graphs. 

The  second  step  for  use  of  the  handbook  involves  reviewing  the 
proposed  hardware,  software,  development  plan,  file  conversion  plan, 
etc.  ,  in  light  of  experience  gained  by  the  Air  Force  in  the  development 
and  operation  of  18  ADP  systems.  The  experience  information  is  re¬ 
trieved  from  18  system  descriptions  through  the  use  of  12  indexes. 
Subsection  I.B.  describes  the  use  of  these  indexes  for  retrieval  of  ex¬ 
perience  information,  while  subsection  I.  C.  describes  the  format  and 
content  of  the  experience  information  in  the  system  descriptions. 

A.  Cost  Estimation 


1 .  Description  of  Iso-Graphs 

Five  sets  of  iso-graphs  representing  the  five  cost  estimation 
equations  and  their  respective  intervals  are  available  for  cost  estimation. 
These  sets  of  iso-graphs  are  identical  in  structure  and  are  contained  in 
Section  II.  Each  set  is  used  for  determining  three  expected  values  for  a 
cost  factor.  Cost  factors  that  may  be  estimated  are  as  follows: 

Development  Cost 


o  Man-months  of  development  effort 
Operations  Cost 


o  Number  of  program  maintenance  personnel 

o  Number  of  operations  personnel 

o  Dollars  per  month  of  hardware  cost  for  application  production 

o  Dollars  per  month  of  hardware  cost  for  program  maintenance 

The  workload  descriptors  from  the  ADPS  proposal  are  used  for  de¬ 
termining  cost  from  the  iso-graphs.  The  workload  descriptors  required 
for  using  all  five  sets  of  iso-graphs  are  as  follows: 

Input  Variables 

o  Characters  per  month  of  input  volume 
o  Number  of  input  data  fields 
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Output  Variables 


o  Characters  per  month  of  output  volume 
o  Number  of  output  formats 

Data  Base  Variable 


o  Characters  in  data  base 

See  Figure  1  for  an  example  of  a  set  of  iso-graphs.  The  set  con¬ 
tains  three  charts,  each  to  be  entered  in  identical  fashion.  The  hori¬ 
zontal  scale  of  the  example  marks  off  the  number  of  input  data  fields, 
while  the  vertical  scale  marks  off  the  number  of  output  formats. 

2.  Obtaining  the  Cost  Estimates 

Follow  the  procedure  of  steps  a  through  g  to  obtain  the  three 
values  of  a  cost  factor. 

a.  Find  the  workload  descriptor  value  for  the  proposed 
ADPS  on  the  horizontal  scale  of  any  one  of  the  three 
iso-graphs. 

b.  Draw  a  vertical  line  through  all  three  iso-graphs  at 
the  value  established  in  step  a. 

c.  Find  the  workload  descriptor  value  for  the  proposed 
ADPS  on  the  vertical  scale  of  each  of  the  three 
iso-graphs. 

d.  Draw  a  horizontal  line  on  all  three  iso- graphs  through 
the  values  established  in  step  c. 

e.  On  the  top  iso-graph,  determine  the  value  that  the  cost 
estimate  is  expected  to  be  less  than,  90  percent  of  the 
time,  by  logarithmically  interpolating  the  intersection 
point  of  the  vertical  (step  b)  and  horizontal  (step  d) 
lines  between  adjacent  iso-lines. 

f.  On  the  center  iso-graph,  determine  the  value  that  the 
cost  estimate  is  expected  to  be,  by  logarithmically 
interpolating  the  intersection  point  of  the  vertical 
(step  b)  and  horizontal  (step  d)  lines  between  adjacent 
iso-lines. 

g.  On  the  bottom  iso-graph,  determine  the  value  that  the 
cost  estimate  is  expected  to  be  greater  than,  90  percent 
of  the  time,  by  logarithmically  interpolating  the  inter¬ 
section  point  of  the  vertical  (step  b)  and  horizontal 
(step  d)  lines  between  adjacent  iso-lines. 
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Number  o f  Input  Dau  Plaid* 
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ta  kilt  had  in  Map  l. 
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7.  On  tha  bottom  lao-graph,  datarmina  tha  valua  that  Mcn-Manth*  of 
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cant  iao-lloaa. 


FIGURE  1  -  COST  ESTIMATING  ISO-GRAPH  FOR  MAN-MONTHS  OF  DEVELOPMENT  EFFORT 


3.  Interpreting  the  Results 


The  results  taken  from  the  three  iso-graphs  have  the  follow¬ 
ing  meaning: 

Top  Iso-Graph  Iso-lines  of  this  chart  give  the  value  the  estimated 
cost  factor  is  expected  to  be  less  than,  90  percent  of  the  time. 

Center  Iso-Graph  Iso-lines  of  this  chart  give  the  value  the  cost 
factor  is  expected  to  be  (50  percent  of  the  time  it  will  be  greater 
and  50  percent  of  the  time  it  will  be  smaller). 

Bottom  Iso-Graph  Iso-lines  of  this  chart  give  the  value  the  cost 
factor  is  expected  to  be  greater  than,  90  percent  of  the  time. 

4.  Using  Estimated  Costs  and  Relevant  Experience 

The  proposed  costs  are  compared  with  estimated  costs 
from  the  top  and  bottom  iso-graphs  to  determine  whether  the  pro¬ 
posed  costs  fall  within  their  respective  prediction  intervals. *  If 
any  of  the  proposed  costs  are  outside  their  respective  prediction 
intervals,  these  costs  are  highly  suspect  of  error  and  should  be 
carefully  examined  using  relevant  experience  data  retrieved  from 
system  descriptions  in  the  handbook.  If  the  proposed  costs  are 
within  their  predicted  intervals,  relevant  experience  data  are  re¬ 
trieved  from  the  system  descriptions  to  verify  the  reasonableness 
of  the  proposed  costs. 

B.  Retrieval  of  Relevant  Experience 

Twelve  indexes  are  available  for  retrieving  information  from  the 
18  system  descriptions.  The  system  descriptions  appear  in  Section  III 
and  indexes  in  Section  V.  Two  of  the  indexes  use  workload  descriptors 
for  retrieval  of  experience,  while  the  other  10  use  other  system  attri¬ 
butes  such  as  functional  area.  The  12  indexes  do  not  exhaust  all  attri¬ 
butes  for  indexing,  but  provide  convenient  tools  for  retrieving  the  bulk 
of  experience  data  in  the  system  descriptions  relevant  to  a  proposed 
system.  This  section  describes  the  manual  procedures  for  retrieving 
information  relevant  to  a  proposed  ADPS  using  each  of  the  12  indexes. 

1 .  Development  Experience  Index 

The  Development  Experience  Index  uses  a  Development  Ex¬ 
perience  Index  Worksheet  (see  Section  V)  in  conjunction  with  a  plastic 
index  card.  The  index  card  is  also  used  with  the  Operations  Experience 
Index.  Figure  2  illustrates  the  parts  of  the  index  card. 


The  prediction  intervals  for  the  cost  estimation  equations  in  this  pilot 
version  of  the  Experience  Handbook  are  rather  wide.  These  wide  inter¬ 
vals  are  largely  due  to  the  small  sample  size  used  in  development  of 
these  equations. 
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Slide  for  use 


with  Operations 
Experience 
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_ Arrow;  This  arrow 

is  placed  at  the  proposed 
value  of  an  operations 
workload  descriptor  scale 

Number  from  Tolerance  Bands:  These 
numbers  are  entered  into  the  Operations 
Ranking  Table  beneath  the  system  name 
falling  in  the  tolerance  band 


Number  from  Tolerance  Bands;  These 
numbers  are  entered  into  the  Develop¬ 
ment  Ranking  Table  beneath  the  system 
name  falling  in  the  tolerance  band 


FIGURE  2  -  PARTS  OF  THE  INDEX  CARD 


To  determine  systems  which  have  relevant  development  experi¬ 
ence,  fill  out  a  Development  Experience  Index  Worksheet  according  to 
the  following  procedures  (also  included  on  the  worksheet): 

a.  Enter  the  proposed  values  for  No,  of  Input  Transac¬ 
tion  Types,  No.  of  Input  Data  Fields,  No.  of  Output 
Formats,  and  No.  of  Data  Base  Record  Types  in  box 
below  the  corresponding  scale. 

b.  Remove  the  index  card  from  the  pocket  and  position 
the  center  arrow  of  the  Development  Slide  at  the  pro¬ 
posed  value  on  the  No.  of  Input  Transaction  Types 
scale. 

c.  For  all  systems  bounded  by  the  Development  Slide, 
enter  the  number  from  the  tolerance  band  in  the  No. 
of  Input  Transaction  Types  row  of  the  Ranking  Table 
beneath  the  corresponding  system  name. 

d.  Repeat  steps  b  and  c  for  No.  of  Input  Data  Fields  and 
No.  of  Output  Formats. 

e.  Repeat  steps  b  and  c  for  No.  of  Data  Base  Record 
Types  if  the  proposed  value  is  not  zero.  If  the  pro¬ 
posed  No.  of  Data  Base  Record  Types  is  zero,  enter 
the  number  3  in  the  Data  Base  row  of  the  Ranking 
Table  beneath  ADOBE,  MISSIM,  and  ORBIT. 

f.  Enter  the  Total  Rank  in  the  bottom  row  of  the  Ranking 
Table.  Total  Rank  is  computed  by  adding  the  numeric 
entries  in  each  column  of  the  Ranking  Table. 

g.  The  system  with  the  largest  Total  Rank  is  the  most 
relevant  system  in  developmental  aspects  to  the  pro¬ 
posed  system.  Relevancy  of  other  systems  is  in  order 
of  Total  Rank.  Systems  with  Total  Rank  equal  to  or 
greater  than  7  are  highly  relevant  to  the  proposed  au¬ 
tomation.  Systems  with  Total  Rank  less  than  7  but 
greater  than  3  have  less  relevance,  but  may  still  be 
used,  while  developmental  experience  data  from  sys¬ 
tems  with  Total  Rank  less  than  or  equal  to  3  should 
not  be  used. 

2.  Operations  Experience  Index 

The  Operations  Experience  Index  uses  an  Operation  Experience 
Index  Worksheet  (Section  V)  in  conjunction  with  the  same  plastic  index 
card  used  for  the  Development  Experience  Index.  See  Figure  2  for  defi¬ 
nition  of  index  card  parts. 
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To  determine  systems  that  have  relevant  operations  experience, 
fill  out  an  Operations  Experience  Index  Worksheet  according  to  the  fol¬ 
lowing  procedures  (also  included  on  the  worksheet): 

a.  Enter  the  proposed  values  for  Char,  /Mo,  of  Input 
Volume,  Char.  /Mo.  of  Output  Volume,  and  Char, 
in  Data  Base  in  the  box  below  the  corresponding 
scale. 

b.  Remove  the  index  card  from  the  pocket  and  position 
the  center  arrow  of  the  Operations  Slide  at  the  pro¬ 
posed  value  of  the  Char.  /Mo.  of  Input  Volume  scale. 

c.  For  all  systems  bounded  by  the  Operations  Slide, 
enter  the  number  from  the  tolerance  band  in  the 
Char.  /Mo.  of  Input  Volume  row  of  the  Ranking 
Table  beneath  the  corresponding  system  name. 

d.  Repeat  steps  b  and  c  for  Char.  /Mo.  of  Output  Volume. 

e.  Repeat  steps  b  and  c  for  Char,  in  Data  Base,  if  the 
proposed  value  is  not  zero.  If  the  proposed  Char,  in 
Data  Base  is  zero,  enter  the  number  3  in  the  Data 
Base  row  of  the  Ranking  Table  beneath  ADOBE, 
MISSIM,  and  ORBIT. 

f.  Enter  the  Total  Rank  in  the  bottom  row  of  the  Ranking 
Table.  Total  Rank  is  computed  by  adding  the  numeric 
entries  in  each  column  of  the  Ranking  Table. 

g.  The  system  with  the  largest  Total  Rank  is  the  most 
relevant  system  in  operational  aspects  to  the  pro¬ 
posed  system.  Relevancy  of  other  systems  is  in  order 
of  Total  Rank.  Systems  with  Total  Rank  equal  to  or 
greater  than  5  are  highly  relevant  to  the  proposed  sys¬ 
tem.  Systems  with  Total  Rank  less  than  5  but  greater 
than  2  have  less  relevance,  but  may  still  be  used, 
while  operational  experience  data  from  systems  with 
Total  Rank  less  than  or  equal  to  2  should  not  be  used. 

3.  Functional  Area  Index 


The  Functional  Area  Index  is  used  to  retrieve  systems  with 
the  same  functional  area  as  the  proposed  ADPS.  All  sampled  ADP  sys¬ 
tems  fall  into  one  of  the  following  functional  areas: 

o  Operations  Supporting 

o  Research  and  Development 

o  Materiel  Management 

o  Personnel  Manpower 
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o  Financial  and  Accounting 
o  Weather 

o  Transportation  Management 

o  Miscellaneous 

To  use  this  index,  find  the  row  of  the  Functional  Area  Index  Table 
(Section  V)  with  the  same  functional  area  as  the  proposed  ADPS.  An 
"X"  will  appear  in  this  row  under  each  sampled  ADPS  with  the  same 
functional  area. 

4.  Decentralized  Operations  Index 

Decentralized  operations  imply  that  an  ADPS  has  a  centralized 
development  with  a  number  of  decentralized  operations  dependent  on  the 
centralized  development  for  system  maintenance  and  support  as  well  as 
delivery  of  the  initial  system  capability.  The  Decentralized  Operations 
Index  is  used  to  retrieve  systems  with  the  number  of  operational  instal¬ 
lations  in  the  same  range  as  the  number  of  operational  installations  of 
the  proposed  system.  Sampled  ADP  systems  are  divided  into  groups 
according  to  the  following  criteria: 

o  Single  Operational  Installations 

o  From  2  to  7  Operational  Installations 

o  From  8  to  100  Operational  Installations 

o  More  than  100  Operational  Installations 

To  use  this  index,  find  the  row  of  the  Decentralized  Operations 
Index  Table  (Section  V)  corresponding  to  the  number  of  operational  in¬ 
stallations  for  the  proposed  ADPS.  An  "X"  will  appear  in  this  row  under 
each  sampled  ADPS  with  the  number  of  operational  installations  in  the 
same  range. 

5.  Multiple  Application  Index 

"Multiple  applications"  refers  to  the  operation  of  more  than 
one  ADPS  at  a  given  computer  installation.  The  Multiple  Applications 
Index  is  used  to  retrieve  systems  with  the  number  of  applications  on  an 
installation  in  the  same  range  as  the  number  of  applications  of  the  pro¬ 
posed  system.  Sampled  ADP  Systems  are  divided  into  groups  according 
to  the  following  criteria: 

o  Single  Application  at  an  Installation 

o  From  2  to  10  Applications  at  an  Installation 

o  More  than  10  Applications  at  an  Installation 

To  use  this  index,  find  the  row  of  the  Multiple  Application  Index 
Table  (Section  V)  corresponding  to  the  number  of  applications  at  an  in¬ 
stallation  for  the  proposed  ADPS.  An  "X"  will  appear  in  this  row  under 
each  sampled  ADPS  with  the  number  of  applications  in  the  same  range. 
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6.  Programming  Language  Index 


Programming  languages  include  procedure-oriented  lan¬ 
guages,  assembly  languages,  and  the  lack  of  any  language  usage  (ma¬ 
chine  language).  The  Programming  Language  Index  is  used  to  retrieve 
systems  using  the  same  type  of  programming  language  in  their  develop¬ 
ment  as  the  proposed  ADPS. 

To  use  this  index,  find  the  row  of  the  Programming  Language  Index 
Table  (Section  V)  with  the  same  programming  language  specified  for  the 
proposed  ADPS,  An  "X"  will  appear  in  this  row  under  each  sampled 
ADPS  using  the  same  programming  language  as  the  proposed  system. 
Since  more  than  one  programming  language  may  be  used  in  a  system  de¬ 
velopment,  the  same  procedure  may  be  repeated  to  retrieve  systems 
using  all  programming  languages  planned  for  use  in  the  proposed  ADPS. 

7.  Processing  Type  Index 

The  Processing  Type  Index  is  used  to  retrieve  systems  with 
the  same  type  of  processing  control  specified  for  the  proposed  system. 
The  processing  types  are  defined  by  the  following  criteria. 

o  Real-time  data  collection 

o  On-line  inquiry  processing 

o  Batched  processing  under  executive  control 
o  Batched  processing  with  no  executive  control 

To  use  this  index,  find  the  row  of  the  Processing  Type  Index  Table 
(Section  V)  corresponding  to  the  processing  type  of  the  proposed  ADPS. 
An  "X"  will  appear  in  this  row  under  each  sampled  ADPS  with  the  same 
processing  type. 

8.  File  Conversion  Index 

The  File  Conversion  Index  is  used  to  retrieve  systems  with 
types  of  file  conversion  similar  to  the  proposed  system.  Types  of  file 
conversion  are  defined  by  the  following  criteria: 

o  No  file  conversion 

o  Conversion  from  manual  to  ADP  system 

o  Conversion  from  PCAM  to  ADP  system 

o  Conversion  from  ADP  to  ADP  system 

To  use  this  index,  find  the  row  of  the  File  Conversion  Index  Table 
(Section  V)  corresponding  to  the  type  of  file  conversion  for  the  proposed 
ADPS.  An  ,fX"  will  appear  in  this  row  under  each  sampled  ADPS  with 
the  same  type  of  file  conversion. 
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9. 


Direct  Access  Storage  Index 


The  Direct  Access  Storage  Index  is  used  to  retrieve  systems 
with  an  amount  of  direct  access  storage  in  the  same  range  as  the  direct 
access  storage  for  the  proposed  system.  Sampled  ADP  Systems  are  di¬ 
vided  into  groups  according  to  the  following  criteria: 

o  No  direct  access  storage 

o  Less  than  10  million  characters 

o  From  10  million  to  50  million  characters 
o  Greater  than  50  million  characters 

To  use  this  index,  find  the  row  of  the  Direct  Access  Storage  Index 
Table  (Section  V)  corresponding  to  the  amount  of  direct  access  storage 
for  the  proposed  ADPS.  An  "X"  will  appear  in  this  row  under  each  sam¬ 
pled  ADPS  with  amount  of  direct  access  storage  in  the  same  range. 

10.  Computer  Cost  Index 

This  index  is  used  to  retrieve  systems  with  computers  of 
approximately  the  same  basic  monthly  rental  cost  as  the  proposed  ADPS. 

If  a  proposed  value  for  basic  monthly  rental  (for  all  applications)  is  avail¬ 
able,  systems  with  approximately  the  same  cost  may  be  located  by  search¬ 
ing  for  rows  with  the  closest  value  of  basic  monthly  rental.  An  "X"  will 
appear  under  each  sampled  ADPS  with  the  same  value  of  basic  rental  cost. 

1 1 .  Computer  Index 


The  Computer  Index  is  used  to  retrieve  systems  using  the 
same  computer  as  the  proposed  ADPS.  In  the  event  that  a  proposed  sys¬ 
tem  does  not  specify  the  computer  to  be  used,  this  index  will  not  be 
applicable. 

To  use  this  index,  find  the  row  of  the  Computer  Index  Table  (Sec¬ 
tion  V)  with  the  proposed  computer.  An  "X"  will  appear  in  this  row  under 
each  sampled  ADPS  using  the  same  computer.  If  the  proposed  ADPS  has 
more  than  one  computer  model,  such  as  a  base  computer  and  peripheral 
computer,  each  computer  must  be  looked  up  individually  in  the  Computer 
Index  Table.  Systems  using  both  the  proposed  base  and  the  peripheral 
computers  should  be  used  in  preference  to  systems  using  the  base  or 
peripheral  computers  individually. 

12.  Security  Index 

The  Security  Index  is  used  to  retrieve  systems  with  the  same 
security  classification  as  the  proposed  system.  Security  classifications 
may  apply  to  any  one  or  all  of  the  following  system  aspects: 

o  Inputs 

o  Data  base 

o  Output 
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o  System  design  and  programs 

o  Hardware 

Sampled  ADP  systems  are  divided  into  four  groups  according  to 
the  following  criteria: 

o  No  aspect  of  system  is  classified 

o  Some  aspect  of  system  is  Confidential 

o  Some  aspect  of  system  is  Secret 

o  Some  aspect  of  system  is  Top  Secret 

To  use  this  index,  find  the  row  of  the  Security  Index  Table  with  the 

highest  classification  of  data  to  be  found  in  the  proposed  ADPS.  An  MXM 
will  appear  in  this  row  under  each  sampled  ADPS  with  the  same  level  of 
security  classification. 

C.  Evaluation  of  Relevant  Experience 


After  the  names  of  relevant  systems  have  been  determined  through 
indexing,  as  described  in  subsection  I.  B,  the  next  step  is  to  examine  the 
system  descriptions  for  relevant  experience  information.  Table  1  en¬ 
ables  one  to  quickly  determine  which  sections  of  a  system  description 
will  contain  experience  information  for  a  given  index.  An  index  may 
select  a  large  number  of  systems  on  a  specific  attribute,  such  as  the 
use  of  COBOL.  To  reduce  the  number  of  systems  examined,  exclude 
systems  first  on  the  basis  of  different  functional  areas  and  then  on  the 
basis  of  a  low  ranking  of  the  Development  and  Operations  Experience 
Indexes.  Subsections  I.C.  1  through  I.C.21  describe  the  format  and 
content  of  sections  in  the  order  in  which  they  appear  in  the  system  de¬ 
scription,  and  also  specify  their  use  in  evaluation  of  experience  data. 

1 .  System 

This  section  of  a  system  description  identifies  the  ADPS  by 
its  title,  the  computer  designation(s),  and  the  acronym  used  for  refer¬ 
ence  throughout  the  handbook.  The  acronym  is  repeated  at  the  top  of 
each  page  of  the  system  description. 

2.  Data  System  Designator 

This  section  of  a  system  description  identifies  the  ADPS  by 
the  USAF  Data  Systems  Automation  Program  (DSAP)  code. 

3.  Data  Collection  Date 


This  section  of  a  system  description  identifies  the  month 
and  year  in  which  the  data  collection  occurred  for  the  ADPS. 

4.  Location 


This  section  of  a  system  description  identifies  the  office  and 
address  to  contact  for  more  detailed  information  on  the  ADPS.  This 
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TABLE  1  -  RELEVANT  SYSTEM  DESCRIPTION  SECTIONS  RETRIEVED  BY  INDEXES 


Sections  of  System 
Description 

Name  of 

Index  N. 

Location 

Function 

Organization 

History 

Schedule 

Description 

Workload 

Hardware 

Software 

Application 

Program 

Development 

File 

Conversion 

Documentation 

Personnel 

Operations 

Application 

Program 

Maintenance 

Benefits 

Cost 

Factors 

Future 

Plans 

Development  Experience 

R 

R 

H 

R 

R 

H 

R 

R 

R 

H 

R 

R 

Operations  Experience 

R 

R 

H 

R 

R 

R 

R 

H 

R 

R 

Functional  Area 

H 

H 

R 

R 

R 

R 

R 

Decentralized  Operations 

H 

R 

H 

H 

R 

R 

H 

R 

R 

H 

R 

R 

Multiple  Application 

R 

R 

H 

Programming  Language 

R 

R 

H 

H 

R 

H 

R 

Processing  Type 

H 

R 

H 

H 

R 

R 

R 

File  Conversion 

R 

R 

R 

R 

H 

R 

Direct  Access  Storage 

R 

H 

R 

R 

R 

R 

Computer  Cost 

R 

R 

R 

H 

R 

H 

R 

Computer 

R 

R 

R 

H 

R 

R 

R 

H 

R 

R 

Security 

H 

R 

R 

R 

R 

R 

R 

H 

Notes:  H  indicates  a  highly  relevant  section. 
R  indicates  a  relevant  section. 


section  also  identifies  the  location  of  development,  location  of  mainte¬ 
nance,  location  of  pilot  installation,  location  of  first  operational  instal¬ 
lation,  and  the  number  of  operational  installations. 

5.  Function 


This  section  of  a  system  description  identifies  the  primary 
user(s)  and  briefly  describes  the  AF  mission  being  supported  by  the 
ADPS  and  the  functions  performed  by  the  system  in  support  of  the 
mission. 

6.  Organization  Chart 

This  section  of  a  system  description  identifies  the  ADPS  or¬ 
ganizational  designator(s) ,  developer(s) ,  user(s),  and  operator(s)  and 
the  relationships  between  them.  Whenever  possible,  the  general  orga¬ 
nizational  framework  shown  in  Figure  3  has  been  adhered  to. 

A  brief  commentary  follows  the  chart,  when  appropriate,  in  an 
attempt  to  explain  special  actions  taken  in  organizing  the  effort  and  the 
ramifications  of  these  actions  on  system  development  and  operation. 

7.  History 

This  section  of  a  system  description  briefly  describes  any 
systems  related  to  the  ADPS  that  may  have  contributed  to  its  develop¬ 
ment.  Proposals  and/or  directives  effecting  the  system  development 
of  the  ADPS  and  significant  milestones  are  identified. 

8.  Schedule 


This  section  of  a  system  description  displays  a  schedule 
showing  all  known  proposed  and  actual  dates  that  may  be  significant  to 
the  development  and  operation  of  the  ADPS.  The  schedule  identifies 
the  actual  development  and  operational  phases  of  the  ADPS. 

9.  Description 

This  section  of  a  system  description  identifies  and  describes 
the  processing  functions  performed  by  the  ADPS.  The  orientation  is 
toward  the  functional  characteristics  of  the  system  rather  than  the  data 
processing  characteristics.  The  section  begins  with  a  narrative  descrip¬ 
tion  of  the  system,  including  descriptions  of  any  unusual  communication 
capabilities  used  to  get  input  to  the  system  and  output  to  the  user.  The 
above  is  accompanied  by  the  system  flow  chart(s)  for  the  ADPS.  The 
system  flow  chart(s)  contain  several  or  all  major  processes  of  the  sys¬ 
tem  at  a  macro  level. 
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FIGURE  3  -  LEVELS  OF  ORGANIZATION 


10. 


Workload 


This  section  of  a  system  description  identifies  the  magnitude 
of  the  ADPS  workload  through  an  information  flow  diagram.  The  diagram 
is  composed  of  four  major  areas:  (1)  inputs,  (2)  data  base,  (3)  process¬ 
ing  functions,  and  (4)  outputs.  These  areas  are  broken  down  as  follows: 

a.  Inputs 

(1)  Characters  per  month  of  input  volume 

(2)  Number  of  input  transaction  types 

(3)  Number  of  input  data  fields 

(4)  Percent  of  input  rejects 

b.  Data  Base 

(1)  Characters  in  data  base 

(2)  Percent  of  characters  on  direct  access  (D/A) 
storage 

(3)  Milliseconds  of  access  time  for  D/A 

(4)  Number  of  data  base  record  types 

(5)  Number  of  data  base  records 

(6)  Percent  growth  rate  per  month 

(7)  Characters  per  month  of  update  input 

c.  Processing  Functions 

(1)  A  vertical  bar  graph  is  used  to  display  the  per¬ 
centage  breakdown  of  source  instructions  and 
hours  of  application  production  by  the  following 
processing  categories: 

(a)  Input  edit 

(b)  File  maintenance 

(c)  Query 

(d)  Sort 

(e)  Merge 

(f)  Compute 

(g)  Report  generation 

(h)  Control 

(2)  The  following  quantities  are  shown  both  for  the 
base  computer(s)  and  for  the  peripheral 
computer(s): 

(a)  Source  instructions 

(b)  Object  instructions 

(c)  Hours  per  month  of  application  production 
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d.  Outputs 


(1)  Characters  per  month  of  output  volume 

(2)  Number  of  output  formats 

(3)  Response  time  (seconds),  if  on-line  system 
11.  Hardware 


This  section  of  a  system  description  identifies  and  describes 
the  hardware  used  by  the  ADPS.  The  section  is  composed  of  two  major 
areas:  (1)  a  hardware  configuration  chart  and  (2)  a  hardware  specifi¬ 
cations  table. 


a.  The  configuration  chart  indicates  model  numbers  and 
hardware  interconnection  of  components  for  all  computers  in  the  system 
by  charts  such  as  that  shown  in  Figure  4. 

b.  The  specifications  table  is  not  a  rigid  format;  it  only 
includes  specifications  for  hardware  present  in  the  system.  Whenever 
required,  the  table  includes  the  following: 


(1)  Computer  model  number 

(2)  First  delivery  date  (month/year) 

(3)  Word  or  character  machine 

(4)  Add  time  (in  microseconds) 

(5)  Internal  storage 

(a)  Effective  cycle  time  (in  microseconds) 

(b)  Word  or  character  size 

(c)  Storage  capacity  in  words  or  characters 

(6)  External  storage 


(a)  Magnetic  tapes 


o  Model  number 

o  Transfer  rate 


(b)  Disk 

o  Model  number 

o  Transfer  rate 

o  Capacity  (in  characters) 

o  Access  time  (in  milliseconds) 


(c)  Drum 

o  Model  number 

o  Transfer  rate 

o  Capacity  (in  characters) 

o  Access  time  (in  milliseconds) 
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REMOTE  LOCATION  EQUIPMENT 


COMPUTER  CENTER  EQUIPMENT 


INQUIRY 

STATION 


CONSOLE 


CARO 

READER 


COMMUNI¬ 

CATIONS 

CONTROL 


CONTROL 


CENTRAL 

PROCESSING 

UNIT 


CONTROL 


CARO 

READER 


TYPE¬ 

WRITER 

PRINTER 


CARO 

PUNCH 


CARO 

READER 


r 


DRUM 

PILE 


CONTROL 


CON 

TROL 

CON 

ITROL 

CONTROL 


CARO 

PUNCH 


DISC 


EQUIPMENT  CHARACTERS 
(Minimum  RuquifiwnH) 


TAPE  STATIONS 


FIGURE  4  -  SAMPLE  CONFIGURATION 


(7)  Peripheral  devices 

(a)  Card  Reader 

o  Model  number 

o  Speed  (in  full  80  char,  cards  per 

minute) 

(b)  Card  Punch 

o  Model  number 

o  Speed  (in  full  80  char,  cards  per 

minute) 

(c)  Printer 

o  Model  number 

o  Speed  (in  lines  per  minute) 

(d)  Paper  Tape  Reader 

o  Model  number 

o  Speed  (in  characters  per  second) 

(e)  Paper  Tape  Punch 

o  Model  number 

o  Speed  (in  characters  per  minute) 

(f)  Communications 

o  Lines  in  multiplexer 

o  Auto -dial 

o  Number  of  consoles  attached 

o  Class  of  service 

(g)  Miscellaneous  Devices 

A  commentary  follows  to  indicate  unusual  hardware  problems, 
conditions  requiring  hardware  modification,  redundancy  or  backup  capa¬ 
bility,  and  characteristics  from  the  chart  or  table  requiring  explanation. 

12.  Software 


This  section  of  a  system  description  identifies  and  describes 
the  support  software  (i.e.  ,  compilers,  assemblers,  executives,  etc.)  used 
as  tools  in  developing  and  operating  the  application  programs  of  the  ADPS. 

A  commentary  follows,  when  appropriate,  in  an  attempt  to  indi¬ 
cate  slippages  in  delivery,  problems  encountered  in  software  usage, 
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special  attributes  that  significantly  assisted  development  and/or  opera¬ 
tion,  and  software  maintenance  support. 

1 3.  Application  Program  Development 

This  section  of  a  system  description  describes  the  signifi¬ 
cant  activities  affecting  development  of  the  application  programs  for  the 
ADPS.  Included  in  the  section  are  descriptions  of  logic  definition,  inter¬ 
action  between  analysts  and  programmers,  programming  techniques, 
and  type  and  extent  of  program  and  system  testing. 

A  commentary  follows,  when  appropriate,  in  an  attempt  to  describe 
any  conditions  existing  during  the  development  phase  of  the  ADPS  that 
may  have  affected  the  development  of  the  application  programs. 

14.  File  Conversion 


This  section  of  a  system  description  describes  the  type  and 
extent  of  file  conversion  activities  required  by  the  ADPS.  Included  in 
the  section  are  descriptions  of  the  format  of  data  prior  to  conversion, 
the  method  of  conversion,  any  special  programs  required  for  the  con¬ 
version,  quality  control  techniques  employed  in  making  the  conversion, 
and  hours  of  computer  use  required  for  conversion. 

15.  Documentation 

This  section  of  a  system  description  lists  all  AFM's,  AFR's, 
OI!s,  etc.  ,  documenting  the  ADPS.  Included  are  descriptions  of  any 
other  types  of  documentation  and  past,  present,  and  future  efforts  to 
document  the  ADPS  during  development  and  operation.  Comments  are 
made  regarding  the  completeness  and  usability  of  documentation  when 
appropriate. 

16.  Personnel 


This  section  of  a  system  description  describes  the  person¬ 
nel  involved  with  the  ADPS  through  the  use  of  a  personnel  table.  The 
table  indicates  the  following  for  managers,  analysts,  and  programmers 
of  the  development  phase,  and  for  managers  and  operators  of  the  oper¬ 
ational  ADPS: 

a.  Number  of  People 

(1)  Sampled 

(2)  Allocated  to  the  system 

b.  Number  of  Years 

(1)  In  ADP 

(2)  In  functional  area 

(3)  Of  college 
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17.  Operations 


This  section  of  a  system  description  begins  with  a  brief  nar¬ 
rative  description  of  the  operation  of  the  ADPS. 

Pie  chart  representations  of  the  computer  utilizations  are  displayed 
for  each  different  computer  used  by  the  ADPS.  For  multi -installation 
systems,  computer  utilization  data  is  taken  from  one  typical  installation. 
The  pie  charts  use  the  following  classifications  of  time: 

a.  For  the  subject  ADPS  or  application 

(1)  Production  time 

(2)  Preparation  time 

(3)  Program  development  and  maintenance 

b.  For  all  other  applications 

(1)  Production  time 

(2)  Preparation  time 

(3)  Program  development  and  maintenance 

c.  Chargeable  lost  time  (by  application  if  possible) 

d.  Set  Up  time 

e.  Idle  time 

f.  Unscheduled  maintenance  time 

g.  Machine  error  lost  time 

h.  Scheduled  maintenance  time 

i.  Off  time 

j.  Other  time 

Each  pie  chart  uses  7  30  hours  as  the  total  available  number  of 
hours  per  month.  This  total  number  is  exactly  one  twelfth  of  the  num¬ 
ber  of  hours  in  a  365-day  year.  The  actual  number  of  hours  used  dur¬ 
ing  a  31 -day  (744-hour)  or  30-day  (720-hour)  month  was  prorated  to 
the  730-hour  standard  used  in  the  pie  charts. 

The  operations  section  ends  with  a  brief  commentary,  when  appro¬ 
priate,  in  an  attempt  to  clarify  any  apparent  or  hidden  reasons  for  un¬ 
usual  utilization  activity  or  lack  of  activity  displayed  in  the  pie  charts. 
The  commentary  also  notes  any  other  unique  operational  characteristics 
of  the  computer  installation  as  a  whole. 

18.  Application  Program  Maintenance 

This  section  of  a  system  description  describes  the  effort, 
techniques,  and  organization  for  all  maintenance  and  continuing  devel¬ 
opment  activities  to  application  programs  after  the  system  was  declared 
operational.  Included  in  the  section,  when  available,  are  indications  of 
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relative  efforts  for  program  corrections  as  opposed  to  improvements 
or  new  development,  and  what  portion  of  the  program  maintenance  per¬ 
sonnel  was  involved  in  the  original  system  development. 

19.  System  Benefits 

This  section  of  a  system  description  identifies  and  describes 
the  primary  advantages  offered  by  the  ADPS.  The  section  is  divided  into 
two  paragraphs.  The  first  paragraph  discusses  the  proposed  benefits  on 
which  the  system  was  originally  justified.  The  second  paragraph  dis¬ 
cusses  the  benefits  actually  realized  by  system  implementation.  Broad 
categories  of  benefits  that  may  be  mentioned  include  cost  savings,  time 
savings,  and  new  capabilities  not  available  prior  to  implementation  of 
this  ADPS. 

20.  Cost  Factors 


This  section  of  a  system  description  displays  eight  develop¬ 
mental  and  operational  cost  factors  in  individual  horizontal  bar  graphs 
showing  the  known  proposed  and  actual  values  of  each  cost  factor.  The 
cost  factors  represent  the  subject  ADPS  and  not  the  whole  ADP  instal¬ 
lation.  Hours/month  of  hardware  use  cost  factors  are  all  prorated  to 
a  standard  month  of  7  30  hours.  The  eight  cost  factors  are  defined  as 
follows: 


a.  Man-Months  of  Development  Effort 

This  is  a  developmental  cost  factor  representing  the 
number  of  man-months  expended  by  manager,  analysts,  programmers, 
and  operators  to  develop  the  ADPS  during  the  development  phase  begin¬ 
ning  with  system  design  and  ending  when  the  system  is  declared  opera¬ 
tional.  During  this  development  phase,  activities  such  as  detailed  sys¬ 
tem  design,  programming,  checkout,  and  equipment  installation  are 
accomplished  as  required. 

b.  Months  of  Elapsed  Development  Time 

This  is  a  developmental  factor  representing  the  number 
of  calendar  months  elapsed  from  the  date  system  design  for  the  ADPS 
is  begun  to  the  date  the  system  is  declared  operational. 

c.  Dollars  of  Hardware  Cost  for  Program  Checkout 

This  is  a  developmental  cost  factor  representing  the 
hardware  cost  for  computer  hours  used  for  program  checkout  during 
the  development  phase  of  the  ADPS. 

d.  Hours/Month  of  Hardware  Use  for  Application  Production 

This  is  an  operational  cost  factor  representing  the 
monthly  computer  hours  on  the  base  computer(s),  charged  to  the  user 
of  the  ADPS  for  processing,  that  are  classified  as  application  production. 
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e.  Hours/Month  of  Hardware  Use  for  Program  Maintenance 

This  is  an  operational  cost  factor  representing  the 
monthly  computer  hours  used  for  application  program  maintenance  of 
the  operational  ADPS  on  the  base  computer(s). 

f.  Number  of  Operations  Personnel 

This  is  an  operational  cost  factor  representing  the  num¬ 
ber  of  personnel  including  operators,  scheduling  personnel,  data  edit 
personnel,  magnetic  tape  librarians,  report  binders,  managers,  etc.  , 
allocated  to  the  ADPS  during  the  operations  phase.  Operations  person¬ 
nel  all  perform  their  functions  within,  and  within  the  immediate  vicinity 
of,  the  computer  room. 

g.  Number  of  Program  Maintenance  Personnel 

This  is  an  operational  cost  factor  representing  the 
number  of  personnel  including  managers,  analysts,  and  programmers 
allocated  to  perform  the  process  of  improving,  changing,  and  correct¬ 
ing  programs  of  the  ADPS  during  the  operations  phase. 

h.  Dollars/Month  of  Hardware  Cost 


This  is  an  operational  cost  factor  representing  the 
cost  of  monthly  computer  hours  used  for  application  production  and  pro¬ 
gram  maintenance  on  the  base  computer(s)  and  peripheral  computer(s). 

Each  horizontal  bar  graph  is  followed  by  commentary  to  clarify 
the  proposed  and  actual  values  of  the  cost  factor  and  to  explain  any  dif¬ 
ferences  between  these  values. 

21.  Future  Plans 


This  section  of  a  system  description  briefly  describes  any 
currently  planned  or  contemplated  changes  or  additions  that  may  affect 


the  ADPS. 


23 


II.  COST  ESTIMATION 
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FIGURE  5  -  COST  ESTIMATING  ISO-GRAPH  FOR  MAN-MONTHS  OF  DEVELOPMENT  EFFORT 
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FIGURE  6  -  COST  ESTIMATING  ISO-GRAPHS  FOR  NUMBER  OF  PROGRAM  MAINTENANCE 
PERSONNEL 
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FIGURE  7  -  COST  ESTIMATING  ISO -GRAPH  FOR  NUMBER  OF  OPERATIONS  PERSONNEL 


FIGURE  8  -  COST  ESTIMATING  ISO-GRAPH  FOR  DOLLARS  PER  MONTH  OF  HARDWARE 
COST  FOR  APPLICATION  PRODUCTION 


.FIGURE  9  -  COST  ESTIMATING  ISO-GRAPH  FOR  DOLLARS  PER  MONTH  OF  HARDWARE 
COST  FOR  PROGRAM  MAINTENANCE 
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III.  SYSTEM  DESCRIPTIONS 
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SYSTEM:  Project  ADOBE  Data  Reduction--ADOBE  (IBM  7040/1401) 


DATA  SYSTEM  DESIGNATOR:  B104 


DATA  COLLECTION  DATE;  May  1966 


Contact  for  Additional  Information 

Air  Force  Rocket  Propulsion  Laboratory 
Edwards  Air  Force  Base 

Edwards,  California 

Development 

Air  Force  Rocket  Propulsion  Laboratory 
Edwards  Air  Force  Base 

Edwards,  California 

Maintenance 

Air  Force  Rocket  Propulsion  Laboratory 
Edwards  Air  Force  Base 

Edwards,  California 

Pilot  Installation 

None 

First  Operational  Installation 

Air  Force  Rocket  Propulsion  Laboratory 
Edwards  Air  Force  Base 

Edwards,  California 

Number  of  Operational  Installations 

1 

FUNCTION:  The  users  of  ADOBE  are  the  Propellant,  Liquid  Rocket,  and  Solid  Rocket  Divisions 
of  the  Rocket  Propulsion  Laboratory.  One  of  the  most  important  missions  of  these  divisions  is  to 
test  and  verify  operation  of  rocket  motors  by  static  firing.  The  exhausts  of  some  of  these  rocket 
motors  contain  hazardous  beryllium  pollutants.  ADOBE  functions  as  a  research  and  development 
support  system  to  predict  the  distribution  and  level  of  these  downwind  pollutant  concentrations  in 
order  to  schedule  and  control  rocket  firings.  ADOBE  reduces  data  recorded  in  r.eal  time  at  a 
rocket  test  site  into  reports  that  aid  the  users  in  evaluating  test  results.  The  data  reduction  is 
performed  in  a  non-real-time  mode. 


ORGANIZATION: 


(User)  (D*v*lop*r/Op«r»tor) 
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HISTORY:  In  1963  the  Air  Force  Rocket  Propulsion  Laboratory  (AFRPL)  and  Air  Force 
Cambridge  Research  Laboratories  directed  Project  Sandstorm,  a  series  of  43  field  tests  to  study 
the  diffusion  of  exhaust  clouds  from  small  solid  rocket  motors  containing  beryllium.  Tests  were 
conducted  with  grains  weighing  from  8  to  65  pounds,  with  their  exhausts  diffusing  over  a  two- 
square-mile  instrumented  course.  The  data  reduction  programs  originated  as  a  part  of  Project 
Sandstorm--the  first  effort  in  the  beryllium  diffusion  area  for  AFRPL.  The  basic  design  for  the 
204*  tower  wind  speed  and  direction  programs  was  embodied  in  an  IBM  650  program  previously 
developed  at  AFRCL.  It  was  planned  to  convert  the  code  directly  to  the  IBM  1401,  but  this  did 
not  prove  feasible  and  the  programs  were  completely  rewritten  for  the  IBM  7040.  Also  in  1963, 
the  original  data  reduction  program  for  exposure  was  written. 

The  test  results  from  Project  Sandstorm  could  not  be  extrapolated  to  larger  motor  sizes  of 
current  interest  with  any  degree  of  confidence.  In  1964  Project  Adobe  began,  using  500-  to  4000- 
pound  grains  that  diffuse  their  exhausts  over  a  28-square-mile  instrumented  course.  Both  pre¬ 
vious  computer  programs  were  extensively  revised,  and  data  reduction  programs  for  temperature 
differential,  12-foot  wind,  and  cloud  tracking  were  added  to  the  capability.  This  programming 
was  completed  in  1965,  with  the  exception  of  cloud  tracking,  which  is  still  continuing. 

Communication  between  the  user  and  the  programmer  analyst  was  informal.  The  user  would 
complete  a  work  order  requesting  a  particular  programming  effort,  and  the  user  and  program¬ 
mer  supervisor  discussed  the  job.  The  user  then  informally  discussed  the  details  with  the  pro¬ 
grammer  assigned  to  the  task.  For  the  remainder  of  the  development  effort,  the  user,  program¬ 
mer  supervisor,  and  programmer  communicated  verbally  approximately  on  a  weekly  basis. 

After  the  program  was  operational,  the  original  programmer  did  any  needed  program  mainte¬ 
nance.  The  programmer  functioned  as  an  analyst,  programmer,  and  maintenance  programmer. 

A  small  amount  of  AFRPL' s  computer  inputs,  outputs,  and  library  tapes  were  classified  as 
confidential,  but  security  measures  have  not  significantly  hindered  ADPS  installation  or  operation 


SCHEDULE: 
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DESCRIPTION;  The  ADOBE  system  reduces  instrumentation  data  obtained  from  a  204-foot  me- 
terological  tower,  12-foot  wind  sets,  air  and  soil  samplers,  and  phototheodolite  cameras.  The 
raw  data  are  converted  from  analog  strip  charts  to  digital  punched  cards  by  an  operator  on  a 
Benson  Lehner  Oscar  J.  ,  or  from  handwritten  reports  directly  to  punched  cards. 
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WORKLOAD: 


PROCESSING 

JUNCTIONS 


HARDWARE: 


1  -  ,  -  — ' 


Swttt  liable  Tape  Units 

IBM  7040  IBM  1401 


Com  - 
puter 

i-  ir  si 
J)eli  V- 

ery 

Mb/Yr 

Wort) 

or 

Clin  r. 
Mach. 

Add 
rime 
(  sj 

Intel  n  il  Storage 

Kxlcrn.il 

Peripheral  Devices 

Card  Reader 

/Punch 

Printer 

Cycle 

Time 

W  o  rd  / 
Char. 
S»7.e 
(bits) 

Word/ 
Char. 
Ca- 
pac  tty 

Stora 

No. 

Read 
Speed 
(cards  / 
min) 

Punch 
Speed 
(cards  / 
min) 

No. 

Speed 

No. 

M-»K 

Tapes 

_ 

Trans. 

Rate 

IBM 

7  04  0 

4/M 

Word 

10 

K 

36 

4,090 

S-  729  II 
1-77.9  IV 

1  5K  to 
62.  SK 

None 

... 

— 

None 

JUKI 

1401 

9/60 

Cha  r. 

2  JO 

1  l.*» 

6 

4K 

4- 

729  V 

60K 

1  - 

1402 

800 

2S0 

1  - 

1403 

600 

Comment:  The  <-<pi i pment  lias  been  highly  reliable:  approximately  98%  uptime. 
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SOFTWARE:  Software  for  the  IBM  7040  consisted  of  an  IBSYS  monitor  executive  system,  a 
FORTRAN  IV  compiler,  and  a  MAP  assembler.  All  software  was  delivered  by  IBM  with  the 
machine  in  September  1963. 

COMMENT:  There  is  currently  one  person  assigned  full  time  to  system  programming  at  RPL. 
His  time^ is  mainly  spent  updating  the  software  according  to  frequent  manufacturer  modifications. 
The  software  has  caused  no  problems  in  the  development  or  operations  of  the  ADOBE  system. 


APPLICATION  PROGRAM  DEVELOPMENT:  Two  of  the  five  ADOBE  data  reduction  programs 
were  extensively  revised  from  Project  Sandstorm  effort  as  discussed  in  the  history  section. 

The  other  programs  were  designed  and  coded  in  FORTRAN  IV  by  contractor  personnel  from 
Telecomputing  Services,  Inc.  ,  who  received  details  by  written  work  order  and  verbal  communi¬ 
cation.  Documentation  was  informal  and  not  at  a  system  level,  because  of  the  extreme  inde¬ 
pendence  of  the  programs,  but  in  the  form  of  program  listings  held  by  the  cognizant  program¬ 
mer.  The  existing  IBM  7040/1401  computer  system  was  used  for  testing  with  no  new  hardware 
or  software  capabilities  required.  Turnaround  time  was  normally  4  to  8  hours.  The  program 
independence  negated  the  need  for  an  integrated  system  test.  Development  is  currently  going  on 
and  records  were  not  kept  of  the  number  of  hours  of  testing  that  have  been  utilized.  Daily  time 
cards,  with  time  allocated  to  the  appropriate  work  order,  and  monthly  time  reports  were  sub¬ 
mitted  during  development.  Program  status  reports  were  kept  by  Telecomputing  Services,  Inc. 
personnel  only. 


FILE  CONVERSION:  No  file  conversion  was  involved  in  ADOBE  development. 
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DOCUMENTATION:  No  formal  documentation  exists. 


PERSONNEL: 


Number  of  People 

Number  of  Years 

Activity 

Function 

Sampled 

Allot  fttcl  to 
System 

In  ADP 

In  Scientific 
Computation 

Of  College 

Manager 

5 

0.1 

10.5 

3.5 

3.0 

Development 

Analyst 

None:  Programmer  a  Function  na  Programmer 

/Analysts 

Programmer 

5 

7 .0 

3.5 

2.0 

3.0 

Operations 

Manager 

5 

0.1 

10.5 

3.5 

3.0 

Operator 

1 

1  .0 

5.0 

3.5 

X 

OPERATIONS:  The  computer  operation  at  RPL  is  staffed  24  hours  a  day  Monday  through  Friday 
and  8  hours  on  Saturday.  It  operates  as  a  closed  shop.  ADOBE  is  one  of  many  applications  on  the 
IBM  7040/1401  system.  Generally,  an  8-hour  backlog  exists.  There  is  no  schedule  other  than 
for  IBM  maintenance.  Processing  is  on  a  normal  and  hot  priority  basis,  with  "first  come  first 
served"  scheduling. 

Comment:  The  idle  time  is  large  for  this  type  of  installation!  possibly  due  to  the  scheduling 
concept. 
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>  hr*,  r 


APPLICATION  PROGRAM  MAINTENANCE:  The  application  program  maintenance  effort  is 
essentially  a  continuation  of  the  application  program  development  effort.  The  development 
programmer  /analysts  are  also  the  maintenance  programmers,  andthe  same  informal  methods 
of  communication  between  them  and  the  user  are  used.  Most  of  the  effort  is  improvement 
rather  than  error  correction. 

COMMENT:  The  program  maintenance  effort  is  driven  by  the  continually  changing  data  re¬ 
duction  requirements.  The  requirements  change  because  new  meteorological  instrumentation 
is  installed  in  the  field  and  because  the  user  desires  different  outputs. 
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BENEFITS:  Proposed:  ADOBE  was  preceded  by  Project  Sandstorm,  which  existed  to  study  the 
exhaust  clouds  From  small,  solid  rocket  motors  with  grain  weights  between  8  and  65  pounds  and 
instrumentation  over  a  2- square-mile  instrumented  course.  Benefits  ADOBE  was  to  offer  above 
Project  Sandstorm  include  the  ability  to  handle  rocket  motors  of  500-  to  4,000-pound  grains, 
instrumentation  over  a  28- square-mile  course,  and  additional  instrumentation.  ADOBE  was  to 
provide  an  improved  data  processing  capability,  which  included  programs  for  processing  temper¬ 
ature  differentials,  outputs  from  12-foot  wind  towers,  and  cloud  trackings. 

Actual:  The  increased  quantity  and  variety  of  instrumentation  required  was  procured,  enabling 
the  test  of  500-  to  4,000-pound  grains.  Testing  was  expanded  to  include  detonation/burn  tests  and 
contamination  tests  as  well  as  diffusion  of  rocket  motor  exhausts.  The  required  data  processing 
capability  was  realized  with  the  exception  of  cloud  tracking,  the  development  of  which  is  continu¬ 
ing  at  present. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (D«v.) 

Proposed:  15  1  1 

Actual:  21  ■■■■■■■ 

Comment:  ADOBE  ia  in  continuing  development  due  to  system  refine¬ 
ments  and  requirement  changes.  The  project's  development  is  estimated 
to  be  90  percent  complete  at  the  current  21  man-months. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  Unk  CZ 

Actual:  25  ■■■■■ 

Comment:  Forty-five  test  firings  were  scheduled  to  be  completed  b«- 
tween  July  1964  and  July  1965,  by  a  test  directive  which  was  prepared  in 
place  of  a  DAP.  At  present,  39  test  firings  have  been  completed.  The 
schedule  slippage  was  due  to  weather  conditions. 

Dollars  of  Hardware  Coat  for  Program  Checkout  (Dev.) 
Proposed:  Unk  CZ 

Actual:  Unk  W 

Comment:  Records  of  computer  hours  for  program  checkout  were  not 
kept.  Records  of  computer  hours  by  application  were  net  produced 
before  1966  except  by  DSAP  code,  which  is  too  general  to  Isolate 
ADOBE  programs. 


Hours/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  Unk  CZ 

Actual:  12  ■■■■■HBIMHi 

Comment:  The  actual  number  reflects  usage  on  the  IBM  7040  during 
April  i 4^6.  Ten  hours  were  used  for  ADOBE  application  production 
on  the  peripheral  IBM  1401. 


Hours /Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 
Proposed:  Unk  CZ 

Actual:  9 

Comment:  The  actual  number  reflects  usage  on  the  IBM  7040  during 
XprlT  1966.  Eight  hours  were  used  for  ADOBE  program  maintenance 
on  the  IBM  1401. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  1  »  1 

Actual:  l.l 

Comment:  In  addition  to  one  operator,  one  manager  spends  10  percent  of 
his  time  on  ADOBE. 

Number  of  Program  Maintenance  Personnel  {Op.) 

Proposed:  1  I  *1 

Actual:  1.2 

Comment:  The  actual  number  of  personnel  Is  prorated  from  7  program¬ 
mers  on  the  basis  of  time  spent  on  ADOBE  program  maintenance.  There 
Is  also  one  system  programmer  assigned  full  time  to" software  maintenance 
for  all  applications  at  RPL. 

Dollars/Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  CIZ 

Actual:  4,363 

Comment:  The  actual  dollar  value  Is  based  on  16  hours  of  application 
production  and  9  hours  of  program  maintenance. 


FUTURE  PLANS:  A  DAP  is  being  processed  for  an  on-line  micrometeorological  recording  and 
display  system  (MICROMET).  MICROMET  will  provide  input  for  further  processing  by  ADOBE. 
Since  MICROMET  will  perform  data  calibration,  formatting  and  editing,  the  processing  time  for 
ADOBE  will  be  reduced.  In  the  MICROMET  system,  meteorological  instrumentation  output  will 
be  fed  through  A/D  converters  to  an  on-line  computer.  The  on-line  computer  will  reduce  the  in¬ 
coming  data  and  drive  output  equipment  including  a  display  map  of  wind  vectors  and  temperature 
readings.  The  number  of  manual  steps  in  preparing  data  for  ADOBE  will  thus  be  reduced,  im¬ 
proving  accuracy  and  timeliness. 
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SYSTEM:  Accrued  Military  Pay  System--AMPS  (NCR390) 


DATA  SYSTEM  DESIGNATOR:  H003A 


DATA  COLLECTION  DATE:  May  1966 


Contact  for  Additional  Information 

Directorate  of  Data  Automation 

Air  Force  Accounting  and  Finance  C,  nter 
3800  York  Street 

Denver,  Colorado 

Development 

Air  Force  Accounting  and  Finance  Center 
Denver,  Colorado 

Maintenance 

Air  Force  Accounting  and  Finance  Center 
Denver,  Colorado 

Pilot  Installation 

Ent  Air  Force  Base 

Colorado 

First  Operational  Installation 

Ent  Air  Force  Base 

Colorado 

Number  of  Operational  Installations 

125 

FUNCTION:  The  users  of  the  system  are  Air  Force  bases  throughout  the  world,  the  Air  Force 
Director  of  Per sonnel  Planning,  and  the  Director  of  the  Budget.  A  common  mission  of  the  users 
is  military  pay  distribution  and  accounting  control.  AMPS  functions  as  a  management  support 
system  to  prepare  paychecks  for  military  personnel  and  to  provide  accrual  accounting  of  the 
military  pay  funds.  The  reports  of  accountability  are  consolidated  at  the  Air  Force  Accounting 
and  Finance  Center  (AFAFC)  and  forwarded  to  the  Air  Force  Director  of  Personnel  Planning  and 
the  Director  of  the  Budget. 


ORGANIZATION: 


(V..r/Op.r.tor)  - - -  Admli\i.lr.tlv.  JU.pon.lbiitty 
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HISTORY;  The  1949  pay  system,  using  a  hand-posted  military  pay  record  for  each  Air  Force 
member,  recorded  the  pay  dollars  actually  disbursed  to  a  member.  It  did  not  record  or  report 
amounts  "earned  by"  and  "properly  payable  to"  each  member  monthly.  Yet  the  total  amount 
earned,  or  accrued,  represented  the  true  total  dollar  liability  against  the  Air  Force  appropria¬ 
tion.  This  liability,  considerably  greater  than  the  total  dollars  actually  spent  in  cash  or  checks, 
is  a  critical  budget  factor  needed  and  wanted  by  the  Director  of  Personnel  Planning  and  the  Di¬ 
rector  of  Budget  in  the  Pentagon. 

From  the  many  pay  studies  and  tests  undertaken  by  Air  Force  specialists  came  two  con¬ 
cepts  for  a  new  pay  system.  The  first  called  for  centralized  control  of  all  Air  Force  pay  ac¬ 
counts  using  a  high-speed  communication  system  linked  to  a  large-scale  computer  at  the  Air 
Force  Accounting  and  Finance  Center  (AFAFC).  The  other  concept  approached  the  problem  on 
a  decentralized  basis,  using  desk-size  computers  at  paying  bases.  Both  systems  prescribed 
mechanized  record-posting  and  provided  for  accumulating  and  reporting  pay  management  data 
on  an  accrual  basis. 

In  October  1962,  Department  of  Defense  Directive  7040.3  directed  all  military  services  to 
implement  an  accrual  accounting  system  for  military  pay  within  2  years.  Since  the  central¬ 
ized  computer  system  could  not  be  operational  within  this  tight  time  frame,  the  Comptroller  of 
the  Air  Force  directed  that  the  decentralized  system  be  implemented  and  operational  by  July 
1964.  The  system  would  be  known  as  the  Air  Force  Accrued  Military  Pay  System  (AMPS). 

Planning  sessions  were  held  in  January  and  February  1962  with  representatives  of  Head¬ 
quarters  USAF,  AFAFC,  and  the  major  air  commands.  The  group's  recommendations  resulted 
in  Headquarters  USAF  being  responsible  for  policy  guidance,  systems  and  program  approvals, 
and  AFAFC  for  systems,  procedures,  and  program  development  and  implementation,  and  the 
major  air  commands  for  full  program  support  and  execution  at  command  and  base  levels. 

The  use  of  the  NCR  390  computer  was  specified  to  the  Air  Force  Accounting  and  Finance 
Center  by  Headquarters,  USAF,  Accounting  and  Finance  and  had  been  used  at  Ent  AFB, 

Colorado,  in  a  single  base  prototype  system.  Operators  of  the  system  were  sent  to  a  special 
Air  Training  Command  School  on  AMPS  at  Sheppard  AFB  prior  to  the  actual  use  of  the  system 
on  an  Air  Force  base.  The  system  is  operational  on  174  computers  located  at  125  Air  Force 
bases. 

The  AMP  system  design  was  a  cooperative  effort  of  the  Directorates  of  Military  Pay  and 
Data  Automation  at  the  Air  Force  Accounting  and  Finance  Center.  The  Directorate  of  Military 
Pay  developed  requirements  for  program  development  and  changes  while  ensuring  the  integrity 
of  the  Military  Pay  System.  The  Directorate  of  Data  Automation  was  responsible  for  system 
analysis  and  programming. 


SCHEDULE; 
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DESCRIPTION:  The  primary  function  of  AMPS  is  to  prepare  paychecks  for  military  personnel. 
The  pay  computations  are  run  twice  a  month.  In  addition  to  check  issuance,  AMPS  has  the  ca¬ 
pability  for  accepting  temporary  and  permanent  pay  changes  for  military  personnel  and  for  pro¬ 
ducing  quarterly  accrual  FICA  (Federal  Insurance  Contributions  Act)  and  FITW  (Federal  Income 
Tax  Withheld)  reports.  A  punched  paper  tape  with  ail  accrued  expenditures  by  categories  is  also 
prepared  by  each  base.  These  tapes  are  sent  by  each  base  to  AFAFC,  which  consolidates  them 
on  the  RCA  501  to  prepare  an  Air  Force-wide  RAOMP  (Report  of  Accrued  Obligations  for  Military 
Pay).  The  RAOMP  report  is  forwarded  to  Hq.  USAF  Director  of  Personnel  Planning  and  the  Di¬ 
rector  of  the  Budget. 


OPENING  or  MILITARY  PAY  RECORD  (MPHI  PROCESS  RETIREMENTS.  DISCHARGES.  TRANSfERS  IN.  TRANSfERS  out 


48 


AMPS  Sheet  4  of  7 


HARDWARE: 


NCR  390-3 
Console  and  Cen¬ 
tral  Processing 
Unit 


NCR  361-1 
Paper  Tape 
Reader 


NCR  381-2 
Card  Reader 
(Modified 
IBM  026) 


NCR  362-1 
Strip  Tape 
Reader 


NCR  462-1 
Paper  Tape 
Recorder 


NCR  390 


Com¬ 

puter 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal  Storage 

Peripheral  Devices 

Cycle 

Time 

(us) 

Word 

Size 

(Nu¬ 

meric 

Char.) 

Word 

Ca¬ 

pacity 

Card 

Reader 

Paper  Tape  Reader 

Paper  Tape  Punch 

No. 

Read 

Speed 

(cards/ 

min) 

No. 

Read 
Speed 
(char.  / 
sec) 

No. 

Punch 
Speed 
(char.  / 
sec) 

NCR 

390 

S/61 

Nu¬ 

meric 

Char. 

11,300 

1,200 

12 

200 

1- 

381-2 

15 

1-361-1 

1-362-1 

400 

1-462-1 

17 

Comment:  The  carriage  of  the  NCR  390  reads  information  from  magnetic  ledger  cards, 
which  contain  up  to  200  words  in  magnetic  strips. 
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SOFTWARE:  The  NCR  390  does  not  have  assemblers,  compilers,  or  an  executive  system. 

Comment:  Conventional  software  is  not  supplied  with  the  NCR  390  because  of  the  extremely 
small  scale  of  the  machine. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  system  design  was  a  cooperative  effort  of  the 
Directorates  of  Military  Pay  and  Data  Automation  within  AFAFC.  The  Directorate  of  Military 
Pay  was  responsible  for  analysis  and  determination  of  military  pay  requirements  and  AMPS 
system  design.  The  Directorate  of  Data  Automation  was  responsible  for  program  design,  coding, 
and  program  checkout.  All  programs  were  written  in  absolute  machine  language.  The  pro¬ 
grammers  operated  their  own  programs,  and  were  able  to  make  roughly  two  checkout  runs  per 
day.  The  computer  operated  two  shifts  a  day,  6  days  a  week  during  program  checkout.  NCR 
allowed  330  days  of  free  use  for  as  many  hours  as  desired.  An  estimate  of  12  hours  a  day  or 
3,744  hours  of  a  possible  7,920  hours  were  used  for  checkout.  The  Directorate  of  Military  Pay 
compiled  an  exhaustive  set  of  test  data  for  the  system  test,  and  subsequently  verified  the  results 
of  the  system  test  with  the  Directorate  of  Data  Automation.  PERT  charts,  progress  charts,  and 
work  measurement  charts  were  maintained  during  development  for  management  control. 


FILE  CONVERSION:  File  conversion  was  performed  on  a  decentralized  basis  by  the  AFO's  re¬ 
sponsible  for  the  payroll  records.  Conversion  was  made  from  manual  payroll  records  to  mag¬ 
netic  ledger  report  forms.  Information  from  manual  payroll  records  was  manually  converted  to 
Form  1926  Alphanumeric  Header  Data  on  punched  cards  and  to  Form  1927  Military  Pay  Record 
Opening  Data  on  punched  paper  tape.  These  inputs  were  then  submitted  to  the  normal  MPR 
opening  subsystem  to  generate  the  master  file  of  MPR's.  At  a  typical  base  the  conversion  proc¬ 
ess  was  accomplished  within  a  cwo-week  period  (between  pay  dates)  using  the  entire  AFO  staff 
(between  15  and  40  people  depending  on  base  size)  working  on  a  two-shift  basis  plus  overtime. 
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DOC  UM  ENT  AT  ION:  The  basic  system  description  and  user's  manual  is  AF  177-105,  which  is  very 
voluminous  and  exhaustive.  Effort  is  presently  being  expended  to  make  the  material  of  this  man¬ 
ual  more  understandable.  The  basic  documentation  of  AMPS  programs  and  program  operation  is 
AF  171-15;  it  contains  program  narratives,  detailed  data  formats,  flow  charts,  and  program  op¬ 
erating  instructions.  Whena  change  is  made  toa  program  affecting  AF  171-15,  a  change  sheet  for 
insertion  or  replacement  is  provided  to  all  bases  along  with  a  new  program  tape.  Any  changes  to 
the  programming  system  are  originated  by  an  "ADP  Projects  Request/ Authorization"  form,  which 
is  signed  and  approved  by  responsible  parties  in  both  the  Directorate  of  Military  Pay  and  Data 
Automation. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Year* 

Sampled 

Allocated  to 
System 

In  ADP 

In  Military 
Pay 

Of  College 

Development 

Manager 

V 

9.3 

12.5 

17.0 

4.5 

Analyst 

23 

23.0 

14.5 

21.5 

U  nknown 

Programmer 

22 

22.0 

4.0 

1.5 

U  nknown 

Operation* 

Manager 

l 

0.5 

2.0 

4.0 

Operator 

6 

3.0 

2.0 

2.0 

X 

OPERATIONS:  The  computer  operation  is  staffed  at  Lowry  AF3  8  hours  a  day,  5  days  a  week. 
It  operates  as  a  closed  shop.  AMPS  is  the  only  application  on  the  NCR  390  computer.  A 
monthly  master  schedule  is  prepared  for  each  of  the  operational  computers  located  throughout 
the  world. 

Comment:  All  development  and  maintenance  of  AMPS  is  performed  on  one  NCR  390  computer 
dedicated  exclusively  to  program  development  and  maintenance  at  AFAFC. 


APPLICATION  PROGRAM  MAINTENANCE:  Problems  arising  at  the  installations  are  transmitted 
to  the  Directorate  of  Data  Automation  at  AFAFC,  where  the  problems  are  analyzed.  The  instal¬ 
lations  are  advised  immediately  of  any  temporary  changes  required  until  the  Directorate  can  re¬ 
lease  a  new  program  tape  and  documentation.  Along  with  the  eight  programmers  involved  in 
program  maintenance  at  AFAFC,  there  are  a  branch  chief  and  systems  analyst  who  also  spend 
full  time  on  the  system.  Sixty  percent  of  the  people  involved  in  program  maintenance  were  in¬ 
volved  in  the  original  development  of  the  system.  The  program  maintenance  activity  is  divided 
into  three  areas:  (1)  program  corrections,  5  percent;  (2)  program  improvements,  25  percent; 
and  (3)  changes  due  to  legislative  requirements  such  as  FICA  and  FITW,  70  percent.  The  aver¬ 
age  turnaround  time  for  checkout  work  is  24  hours. 

Comment:  None. 
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BENEFITS; 

Proposed:  Benefits  which  AMPS  was  designed  to  provide  that  the  existing  manual  system  did  not 
provide  include:  (1)  reporting  of  military  pay  accounting  information  on  an  accrual  basis  to  the 
Director  of  Personnel  Planning  and  the  Director  of  the  Budget;  (2)  more  timely  reporting  of 
military  pay  accounting,  FICA,  and  FITW  data;  and  (3)  a  net  cost  saving  of  approximately  $1.7 
million  annually.  This  was  justified  on  an  estimated  saving  of  approximately  1,200  military  pay 
personnel.  The  personnel  saving  would  be  $6.0  million  while  added  machine  rental  and  mainte¬ 
nance  would  be  $4.3  million,  resulting  in  a  net  saving  of  $1,7  million  annually. 

Actual:  (1)  reporting  of  military  pay  accounting  information  on  an  accrual  basis  to  the  Director 
of  Personnel  Planning  and  the  Director  of  the  Budget  was  accomplished;  (2)  more  timely  report¬ 
ing  of  military  pay  accounting,  FICA  and  FITW  data  was  accomplished  after  some  initial  prob¬ 
lems  with  the  AMPS  computer  system  and  operations  personnel;  and  (3)  revised  manpower  re¬ 
quirements  permitted  the  elimination  of  only  approximately  240  personnel,  corresponding  to 
about  $1.2  million  annually.  Since  additional  equipment  costs  were  $4.3  million,  this  resulted 
in  a  net  annual  additional  cost  of  $3.1  million  over  the  existing  manual  system. 


COST  FACTORS: 


Man-Month*  of  Davalopmant  Effort  (Dev.) 

Propo  •  Unk  Q 

Actual:  704  mmmmammm 

Comma nt:  No  formal  DAP  wu  prepared  for  AMPS.  A  DOD  diractlva 
ot  Octobar  1962  dlractad  that  all  branchaa  of  tha  aarvica  aatabliah  ac¬ 
crual  pay  ayatama  by  Octobar  1964.  Thia  diractlva  did  not  atata  an 
aatlmata  for  man-montha  of  davalopmant  affort. 

Month*  of  Elapaad  Davalopmant  Tima  (Dav.) 

Propoaad:  Hi  - ' - -  "^3 

Actual:  1 8  ■■■■■■■ 

Commant:  July  1.  1964  waa  tha  oparatlonal  data  aatabliahad  by  Hq. 

U5AF. 

Dollar*  of  Hardware  Coat  for  Program  Chackout  (Dav.) 
Propoaad:  Unk  CE 

Actual:  37.178 

Commant:  Tha  numbar  of  hour*  of  actual  chackout  waa  3.744  hour*.  Thia 
waa  computed  by  multiplying  a  productive  chackout  aatlmata  of  12  houra/ 
day  by  344  day*,  tha  actual  numbar  of  day*  uaad  for  program  chackout. 
NCR  allowed  330  day*  of  unlimited  daily  free  uaa  for  chackout. 

Houra /Month  of  Hardwara  Uaa  for  Application  Production  (Op.) 

Propoaad:  Unk  CL 

Actual:  277  rnmmmmmmmi 

Comment:  Tha  actual  numbar  reflect*  uaaga  on  the  NCR  390  during 
March  1966  at  Lowry  AFB. 


Hour  a /Month  of  Hardware  Uaa  for  Program  Maintenance  (Op.) 
Propoaad:  0 1 

Actual.  0 1 

Commant:  All  AMPS  program  maintenance  la  dona  only  at  AFATC.  where 
it  ia~a *tlmated  that  176  houra/month  arc  uaad  for  that  purpoee.  The  NCR 
390  at  AFAFC  la  uaad  only  for  AMPS  program  maintenance. 

Numbar  of  Operation*  Paraonnal  (Op.) 

Propoaad:  3.41  » 

Actual:  3.3  WMaMH 

Commant:  The  actual  numbar  rapraaanta  three  full-time  operator*  and  on* 
analyat~3* voting  30  percent  of  hi*  time  to  AMPS  at  Lowry  AFB.  Thar*  ar* 
two  full-tima  AMPS  operator*  at  AFAFC. 

Numbar  of  Program  Maintenance  Paraonnal  (Op.) 

Propoaad:  0 1 

Actual:  0 1 

Comment:  Tha  actual  numbar  rapraaanta  maintenance  programmers  at  any 
operational  alt*.  Eight  maintenance  programmer*  at  AFAFC  perform  all 
AMPS  maintenance.  A  branch  chief  and  on*  analyat  alao  a  pa  ad  full  time  on 
AMPS. 


Dollara/Month  of  Hardwara  Coat  (Op.) 


Propoaad:  1,724  f—  i 

Actual:  1.723 

Commant:  Thia  amount  la  tha  baalc  rental  charge  par  month  for  a  alngl* 
KICR  390  at  any  oparatlonal  aita  and  the  NCR  390  uaad  axclualvaly  for  pro¬ 
gram  maintenance  at  AFArC. 


FUTURE  PLANS:  AMPS  is  a  decentralized  interim  system  which  was  quickly  implemented  to 
meet  a  DOD  directive.  Future  plans  call  for  the  installation  of  a  Centralized  system  to  replace 
AMPS.  System  study  of  the  centralized  system  is  presently  being  conducted. 
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SYSTEM:  Data  Services  Workload  Control  System--DSWC  (IBM  7080/1401) 


DATA  SYSTEM  DESIGNATOR;  P044 


DATA  COLLECTION  DATE:  July  1966 


LOCATION: 


Contact  for  Additional  Information 

SACS  San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

San  Antonio,  Texas 

Comptroller  (Data  Management  Division) 
Hq.  ,  Air  Force  Logistics  Command 
Wright- Patter  son  Air  Force  Base 

Dayton,  Ohio 

Development 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Ogden  Air  Materiel  Area 

Hill  Air  Force  Base 

Utah 

Comptroller  (Data  Management  Division) 
Hq. ,  Air  Force  Logistics  Command 

Wright -Patter  a  on  Air  Force  Base 

Ohio 

Maintenance 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Pilot  In  eta  llation 

Hone 

Fir  at  Operational  Installation 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Number  of  Operational  Installation* 

8 

FUNCTION:  The  users  of  DSWC  are  the  Data  Center  and  Data  Services  of  the  AFLC  Air 
Material  Areas,  and  the  Data  Center  and  Data  Management  Division  of  Headquarters  AFLC. 
The  mission  of  the  users  is  the  efficient  processing  of  data  and  the  generation  of  desired 
information  products.  DSWC  functions  as  a  management  support  system  to  provide  a  standard 
system  for  use  by  the  AFLC  Data  Centers  for  the  identification  and  control  of  data  services 
operations  and  products  and  the  scheduling  of  data  services  resources.  It  also  provides  the 
Data  Management  Division  of  Headquarters  AFLC  with  management  reports  containing  the 
actual  and  forcasted  use  of  automatic  data  processing  equipment  and  personnel. 


ORGANIZATION: 


(Developer/Ussr) 


AM  A  Data  Cantar 


(Oparator/Uaar) 
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HISTORY:  Prior  to  1963  several  efforts  to  develop  automated  methods  for  manpower  control 
and  workload  scheduling  were  underway  at  Headquarters  Air  Force  Logistics  Command  (AFLC) 
and  at  some  of  the  AFLC  Air  Materiel  Areas  (AMA's),  The  manager  of  the  Data  Management 
Division  of  Headquarters  AFLC  became  aware  of  the  duplicated  efforts  and  formed  a  task  force 
with  the  responsibility  to  develop  a  means  of  consolidating  these  efforts  into  a  single  automated 
system.  The  task  force  derived  a  data  system  specification  in  a  report  titled  The  Automatic 
Data  Processing  Resources  Management  System  (ARMS).  The  AMA*s  received  this  report  in 
August  1963  and  tSeir  criticism  and  comments  were  requested.  After  receiving  their  replies, 
the  system  was  redesigned  and  the  specifications  in  the  form  of  a  DAP  were  submitted  to 
AFADA.  Based  on  verbal  approval  by  AFADA,  the  Data  Management  Division  of  AFLC  beg  n 
work  on  the  project  in  January  1964.  The  San  Antonio  Air  Materiel  Area  (SAAMA)  was  desig¬ 
nated  as  the  development  site  with  support  supplied  by  Ogden  Air  Materiel  Area  (OOAMA).  The 
proposed  initial  operational  date  of  July  1964  proved  unreasonable  and  was  changed  to  October 
1964.  The  sys tern  went  operational  simultaneously  at  all  AMA's  in  January  1965. 

A  system  monitor  from  the  Data  Management  Division,  Headquarters  AFLC,  supervised 
the  entire  development  at  SAAMA.  Analysts  were  located  at  SAAMA  and  two  programming 
groups  were  formed,  one  at  SAAMA  and  one  at  OOAMA.  The  group  at  OOAMA  was  in  daily 
telephone  contact  with  the  analysts  at  SAAMA  throughout  the  system  development. 

DSWC  is  operational  at  the  following  eight  sites:  Rome  AMA,  Sacramento  AMA,  San 
Bernardino  AMA,  San  Antonio  AMA,  Oklahoma  City  AMA,  Ogden  AMA,  Warner  Robbins  AMA, 
and  Hq.  AFLC. 


SCHEDULE: 
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DESCRIPTION:  The  Data  Services  Workload  Control  system  identifies,  plans,  controls,  and 
schedules  all  AFLC  data  services  operations.  The  AFLC  data  processing  installations  are  pro¬ 
vided  with  uniform  procedures  for  manpower  and  EDPE  scheduling  and  other  benefits  such  as 
mechanically  prepared  operator  instructions  (run  sheets),  external  tape  labels,  and  partially  pre¬ 
punched  utilization  cards.  Headquarters,  AFLC,  receives  data  showing  actual  and  forecast  use 
of  system  analyst/programmer  personnel  by  data  system  at  each  installation  as  well  as  showing 
EDPE  use  by  data  system,  projected  by  12  months  (AF-E6,  part  8B).  Inputs  consist  of  man¬ 
power  and  EDP  utilization  in  the  form  of  either  cards  or  reports  punched  on  cards.  The  outputs 
consist  of  a  series  of  reports  on  data  system  equipment  and  requirements,  labor  (programmer/ 
analyst)  availability,  monthly  and  daily  work  schedules  and  status  reports,  and  a  master  di¬ 
rectory  of  mechanized  operations. 


To  tlq.  ,  USA  I 


Out  pul  to  ADI* 
Manager.  Monthly 


ADP  Operation. 


To  Cogni.anl 
Programmer,  and 
ADP  Manag.ra 


ADP  Programming 

Manager. 
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DATA  BASE 

Char,  in  Data  Baae: 

17,270,000 

Percent  of  Char,  on  D/A  Storage: 

NA 

Mllllaeconda  of  Acceaa  Time  for  D/A: 

NA 

No.  of  Data  Baae  Record  Typea: 

3 

No.  of  Data  Baae  Recorda: 

203,500 

Percent  Growth  Rate/Mo. : 

0.2 

Char.  /Mo.  of  Update  Input: 

1,836,000 

WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char.  /Mo.  of  Input 

1 

Volume: 

1,836,000 

No.  of  Input  Trana* 

action  Typea: 

38 

No.  of  Input 

Data  Field  a: 

237 

Percent  of  Input 

Rejecta: 

Unk 

♦ 


K.y 


%  #  .5 

}u  CJ 


t 

« 

i 


lOOf. 
90 
80 
70 
60 
50 
40 
30 
20 
10 
0 % 


LJt 


ft 


t 

u 


A 


Total  Source  Instruction*: 
Total  Object  Inatructiona: 
Hra./Mo.  of  Application 
Production: 


Baae  Computer(a) 

208,100 
208,100 


Peripheral 
Compute  r(  a) 

Unk 

Unk 

67 


Char.  /Mo.  of  Out* 

put  Volume: 

13,070,000 

No.  of  Output 

Formate: 

33 

Reeponee  Time 

(second*): 

NA 

HARDWARE: 


IBM  1406 

IBM  1401 

Core 

Central 

Storage 

Proceeeing 

Unit 

Unit 

IBM  1403 
Printer 


IBM  1402 
Card 

Read/Punch 


2-IBM  7080' e 


2-lBN 
729-IV 
Tape 
Unite  . 


4-IBM  1401'e 


•IBM  1401 


Com¬ 

puter 

Firet 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(as) 

Internal  Storage 

External 

Storage 

Peripheral  Devicee 

Card  Reader  /Punch 

Printer 

No. 

Read 

Speed 

(carde/ 

min) 

Punch 
Speed 
(carde / 
min) 

No. 

Speed 

(1pm) 

Cycle 
Time 
(u  •) 

Cha  r. 
Sire 
(bite) 

Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapee 

T  rane. 
Rate 

2-IBM 

7080 

9/61 

Char. 

11 

2 

6 

160,000 

20- 
729  VI 

to 

90K 

None 

— 

— 

None 

4  -IBM 
1401 

9/60 

Char. 

230 

11.5 

6 

8,192 

2- 

729  IV 

22.5K- 
62. 5K 

1402 

800 

250 

1- 

1403 

600 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8.192 

4- 

7  29  II 

1  5K- 
41. 6K 

1402 

800 

250 

1- 

1403 

600 

Comment:  The  equipment  configuration  varies  with  the  installation,  both  between  AMA'e 
and  Hq  AFLC.  The  configuration  depicted  above  is  for  the  San  Antonio  AMA, 
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SOFTWARE:  Software  for  both  the  IBM  7080  and  IBM  1401  consisted  of  an  Autocoder 
assembler  and  general  input  and  output  utility  routines.  The  IBM  7080  also  had  a  sort 
program  available. 

Comment:  The  software  is  maintained  by  IBM.  The  DSWC  system  used  the  available 
software  extensively. 


APPLICATION  PROGRAM  DEVELOPMENT:  Policy  and  system  design  criteria  were  developed 
under  the  direction  of  the  Data  Management  Division,  Hq.  AFLC.  SAAMA  personnel, 
augmented  by  personnel  from  OOAMA,  were  responsible  for  the  development  and  initial  im¬ 
plementation.  The  programmers  coded  the  programs  in  Autocoder  II  from  flow  charts  and 
specification  documents.  Each  program,  17  for  the  IBM  1401  and  9  for  the  IBM  7080,  was 
checked  out  independently  at  both  SAAMA  and  OOAMA  using  the  partially  built  files  which 
were  being  built  at  each  site  on  already  existing  hardware  common  to  all  AMA's  and  AFLC. 

The  system  checkout,  which  lasted  two  weeks  and  used  live  data,  was  performed  at  SAAMA 
with  some  assistance  from  OOAMA  personnel.  The  computer  checkout  hours  were  mostly 
on  the  IBM  1401  with  1,350  hours  logged  and  the  IBM  7080  with  230  hours  logged.  Each  program 
was  well  documented,  as  was  the  entire  system  design  during  development  by  2  or  3  persons 
involved  full  time  with  documentation.  The  entire  development  was  supervised  by  a  system 
monitor  from  the  Data  Management  Division,  Hq.  AFLC. 


FILE  CONVERSION:  An  extensive  period  of  file  conversion  went  on  simultaneously  with  the 
development  of  the*  system.  The  three  files,  A,  B,  and  C,  had  to  be  built  to  help  with  check¬ 
out.  Checkout  at  both  Ogden  and  San  Antonio  was  performed  with  these  partially  built  files. 

Two  individuals  were  required  full  time  to  build  these  files  at  each  AMA.  One  was  the  system 
monitor,  who,  together  with  a  clerk  assistant,  worked  closely  with  the  individual  programmers 
of  each  AMA.  All  programmer /analysts  in  AFLC  were  required  to  participate  part  time  in 
the  collation  of  program  data  for  the  files.  It  took  about  five  months  to  complete  these  files 
at  the  AMA* 8. 
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DOCUMENTATION:  Each  program  was  initially  documented  with  a  file  of  input  and  output  formats  and 
a  description  of  the  system  design.  During  the  development  phaBe  2  or  3  persons  worked  full  time  with 
documentation.  The  major  documents  of  this  syBtemare  (1)  Data  Services  Workload  (P044),  AFLCM 
300-38,  26  Aug.  1964  (a  users*  manual  and  system  description  with  format  specifications);  (2)  main¬ 
tenance  documents  (a  file  containing  program  listing,  transmittal  letters  with  attachments,  etc.);  and 
(3)  related  documents  on  administrative  regulation,  such  as  AFLCR  300-10,  which  are  used  to  create 
or  modify  files  of  P044. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Area 

Of  College 

Development 

Manager 

1 

1 

20 

20 

Unknown 

Analyst/Programmer 

16 

16 

11 

11 

Unknown 

Operations 

Manager 

4 

0.1 

Unknown 

Unknown 

Unknown 

Operator 

89 

2 

2 

Unknown 

XT 

OPERATIONS:  The  computer  operation  is  staffed  at  SAAMA  24  hours  a  day,  7  days  a  week.  It 
operates  as  a  closed  shop.  DSWC  is  one  of  many  applications  on  the  IBM  7080's  and  1401  's. 
DSWC  is  the  master  scheduler  for  both  the  daily  and  the  monthly  schedules.  The  daily  schedule 
for  each  computer  is  displayed  on  closed  circuit  TV.  Five  IBM  1401  computers  are  used  to 
process  DSWC.  The  pie  chart  below  reflects  utilization  as  if  one  IBM  1401  did  all  of  the  DSWC 
application  processing,  and  not  all  five  computers,  which  is  actually  the  case. 

Comment:  The  SAAMA  installation  does  all  the  program  development  and  maintenance  for  all  the 


operational  sites  of  DSWC. 


Production 
(DSWC  «pp) 

2  hr.  1% 

Prog  Dev  and 
Mt  (DSWC  app) 

2  hr.  1% 

Prod  (all  other 
app.)  4  31  hr.  57% 


Prog  Dev  and 
Mt  (.11  other 
app.)  69  hr.  9% 


OH 

157  hr.  21% 


Prod  (DSWC  app) 

12  hr.  H 

Prog  Dev  A  Mt  (DSWC  app) 
7  hr.  I  $ 

Prod  (all  other  app.) 

35S  hr.  49)1 


Prog  Dev  A  Mt  (all  other  app.) 
9*  hr.  13# 


Prod  (DSWC 
app)  67  hr.  9% 
Prog  Dev  A  Mt 
(DSWC  app) 

14  hr.  2% 

Prod  (all  other 
app.)  284  hr.  39% 


Chg  Lo.t  (.11 
other  app.)  1  hr  t% 


Prog  Dev  A  Mt 
(all  other  app.) 
70  hr.  10% 


IBM  1401  (A) 


APPLICATION  PROGRAM  MAINTENANCE:  The  program  maintenance  is  currently  performed 
at  SAAMA  by  programmer /analysts  who  were  all  involved  in  the  original  development  of 
DSWC.  Problems  arising  at  any  of  the  AMA's  are  isolated  and  pertinent  information  is  trans¬ 
mitted  to  SAAMA.  Resultant  corrections  from  SAAMA  are  inserted  at  each  AMA  by  resident 
analysts  or  programmers. 

Comment:  None. 
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BENEFITS:  Proposed:  DSWC  was  designed  to  provide  ADP  management  with  responsive  tools 
to  make  timely  and  accurate  decisions  on  ADP  resources  (including  ADP  personnel  and  ADPE) 
utilization.  DSWC  was  to  make  uniform  methods  of  computing,  scheduling,  and  reporting  avail¬ 
able  throughout  the  AFLC.  Computer  operations  also  were  to  be  simplified  and  streamlined  by 
providing  operator  sheets,  tape  labels,  and  partially  prepunched  computer  utilization  cards. 

Actual:  DSWC  is  operational  on  an  IBM  7080/1401  system  at  each  Air  Materiel  Area  (AMA)  of 
the  AFLC.  Scheduled  operations  are  put  on  a  large  board,  which  is  then  displayed  by  closed 
circuit  TV  to  the  operator.  DSWC  also  provides  Hq.  AFLC  with  forecasts  of  ADPE  and  ADP 
personnel  use,  and  subsequently  compares  actual  usage  with  the  forecast. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev.) 

Proposed;  UnkCZ 
Actual; 

Comment:  A  task  force,  formed  at  Hq.  AFLC  In  early  1963,  prepared 
a  report  called  the  ADP  Resources  Management  System  (ARMS).  The 
system  specifications  from  this  report  were  used  to  prepare  a  DAP  In 
August  1963,  which  was  approved  verbally  by  AFADA  In  January  1964 
and  officially  In  May  1964.  No  estimate  of  man-months  was  contained 
in  the  DAP. 


Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  61  1 

Actual:  MHHHHi 

Comment:  The  DAP  stated  that  command-wide  implementation  would  be 
completed  by  I  September  1964.  The  programming  phase  of  development 
took  longer  than  planned,  causing  schedule  slippage. 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 
Proposed;  UnkQ 

Actual:  140,660HHHHH 

Comment:  Program  checkout  required  230  hours  on  the  IBM  7080  com- 
puter  and  1,350  hours  on  the  IBM  1401  computer. 

Hours/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  101  ) 

Actual; 

Comment:  Sixty-seven  hours  were  used  for  DSWC  application  production 
on  the  peripheral  IBM  1401's.  The  actual  number  reflects  usage  during 
March  1966  on  the  IBM  7060.  The  DAP  stated  an  estimate  of  30  hours/ 
month  per  AMA  for  the  IBM  1401  computers. 


Hours/Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 
Proposed:  Unk  Q 

Actual:  9 

Comment:  The  actual  number  reflects  usage  during  March  1966  on  the  IBM 
Program  maintenance  for  DSWC  Is  done  only  at  SAAMA.  The  opera¬ 
tional  AMA's  and  Hq.  AFLC  have  monitor  programmer /analysts  who  collect 
program  error  data  to  send  to  SAAMA  and  Install  corrections  from  SAAMA. 
Fourteen  hours  were  used  for  DSWC  program  maintenance  on  the  peripheral 
IBM  1401's  at  SAAMA. 


Number  of  Operations  Personnel  (Op.) 

Proposed:  Unk  f~7 

Actual;  2  BI^BH^BHiHB 

Comment:  The  actual  number  of  personnel  Is  prorated  from  89  operators 
at  SAAMA  on  the  basis  of  machine  time  used  for  DSWC. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  5 

Comment:  The  actual  number  of  personnel  represents  full-time  DSWC 
maintenance  programmer/analysts  at  SAAMA.  There  are  programmer/ 
analysts  at  each  AMA  and  at  Hq.  AFLC  who  Isolate  problems  and  transmit 
program  errpr  data  to  SAAMA  for  correction,  as  well  as  Install  program 
corrections  from  SAAMA. 

Dollars /Month  of  Hardware  Cost  (Op.) 

Proposed:  1.208  0 

Actual:  10.960  BBBHH^BM 

Comment:  The  actual  dollar  amount  includes  the  cost  of  program  main¬ 
tenance  done  only  at  SAAMA.  This  program  maintenance  cost  Is  approx¬ 
imately  $4,289  per  month  at  SAAMA. 


FUTURE  PLANS: 

time. 


There  are  no  indications  of  changes  or  additions  to  this  system  at  this 
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SYSTEM:  Base  Level  Inventory  Control  System--GE/BSS  (GE  225) 


DATA  SYSTEM  DESIGNATOR:  D002 


DATA  COLLECTION  DATE:  April  1966 


LOCATION: 


Contact  for  Additional  Information 

Directorate  of  Data  Automation 

Military  Airlift  Command 

Scott  Air  Force  Base 

Belleville,  Illinois 

Development 

Scott  Air  Force  Base 

Illinois 

Maintenance 

Scott  Air  Force  Base 

Illinois 

Pilot  Installation 

None 

First  Operational  Installation 

Scott  Air  Force  Base 

Illinois 

Number  of  Operational  Installations 

7 

FUNCTION:  The  prime  users  of  GE/BSS  are  the  base  supply  offices  at  the  various  Military 
Airlift  Command  bases.  The  only  other  user  is  the  Accounting  and  Finance  Office,  which 
processes  the  financial  aspects  of  the  inventory  system.  The  mission  of  the  prime  user  is 
controlling  the  distribution,  ordering,  and  inventory  level  of  aircraft  replacement  parts  for 
the  Military  Airlift  Command.  GE/BSS  functions  as  a  management  support  system  in 
processing  real-time  supply  transactions  and  generating  management  reports. 


ORGANIZATION: 


(Operator) 


<U..r) 
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HISTORY:  GE/BSS  evolved  from  an  attempt  in  the  late  1950*8  to  simultaneously  introduce 
automation  techniques  to  a  variety  of  the  Military  Airlift  Command  (MAC)  functions  using  an 
IBM  7070  computer  at  Charleston  AFB.  The  attempt  was  too  ambitious  for  the  system  tech¬ 
nology  of  the  period  and  resulted  in  degrading  the  inventory  function  as  the  requirements  for 
real-time  operation  could  not  be  met. 

Headquarters  USAF  decided  to  transfer  the  functions  one  at  a  time  to  another  computer 
and  employ  the  modular  concept  of  design.  Of  the  33  functions  in  the  Charleston  system,  base 
supply  was  given  the  highest  priority  for  the  new  system  and  is  the  only  function  presently  oper¬ 
ating  in  the  new  computer. 

The  project  began  at  Scott  AFB  in  April  1962  with  the  programming  a  joint  Air  Force 
and  General  Electric  effort.  The  amount  of  coding  required  was  underestimated  and  therefore 
the  available  manpower  was  insufficient  to  meet  the  schedule.  An  additional  time-lag  factor 
in  development  was  the  inclusion  of  new  requirements  and  design  factors  for  MLLSTRIP.  The 
system  became  operational  at  Scott  AFB  in  December  1962  and  during  the  next  18  months  six 
more  similar  systems  were  developed  for  installation  at  other  bases  in  the  Military  Airlift 
Command. 

System  analysts  from  the  Base  Supply  Office  provided  technical  guidance  to  the  General 
Electric  programmers.  The  number  of  contractor  programmers  was  inadequate  and  Air  Force 
and  Civil  Service  programmers  were  added  to  the  effort.  Small  groups  under  close  supervision 
of  Air  Force  programmers  were  formed  and  assigned  specific  tasks  for  the  remainder  of  the 
development. 

UE/BSS  is  operational  at  the  following  seven  AFB*s:  Lajes  AFB,  Travis  AFB,  Scott  AFB, 
Hunter  AFB,  McGuire  AFB,  Charleston  AFB,  and  Dover  AFB. 


SCHEDULE: 
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DESCRIPTION:  There  are  two  main  system  functions:  (1)  posting,  i.e.  ,  the  processing  of 

real-time  supply  transactions,  and  (2)  report  generation.  Posting  input  is  by  punched  cards 
representing  supply  transactions;  for  example,  a  request  for  an  aircraft  part  by  maintenance 
or  the  recording  of  new  stock  purchases.  Each  transaction  updates  the  supply  record  on  the 
disk  and  records  the  transaction  on  the  history  tape,  A  requisition  form  is  output  when  s  part 
has  been  requested.  The  history  tape  is  used  to  produce  management  reports. 


Prom  Supply  Pereonnel  „ 


Supply  Tr.n.ic 
lion,  l,,u, 
Requeet 
Receipt,,  etc. 


POSTING  FUNCTION 

Requisitioning 
end  Receipt, 

Shipping 

Procedure, 

Stock 

Control 

— 

1 

Property 

Accounting 

•» 

executive 

Routine 

•» 

Special 
Logistical 
Precede rea 

l 

Proc«4yrt« 

Turn  in 
Procedure, 

Baa,  Funded 
Item 

Management 

b 


To  Supply  Personnel 


To  Supply  Pereonnel 


Received  From  Supply. 

Office, 


Special  Input 
Card,  lo 
Control 
Reporting 


3H 


REPORTING  FUNCTION 

Summariae 

Select 

Fermat 

Data 

Data 

Data 

Merge 

Sort 

Output 

Data 

Data 

Data 

Daily: 

Pooling  Traneaitioi 
Re, taler.  Reject 
l.tei  In,,  etc . 


Semi-Annual: 

P ret, sue  Inventory 
l.latln,. 

Unit  Price  Review 
lill 


Quarterly: 

Item  Record  dating. 
Detail  Due  In/Out 
dating,  etc. 


Monthly: 

Baee  Supply  Report, 
Potting  Tran, action 
Register,  etc. 


A,  Required: 

Due  Out  on  Deactivated 
Organlaatlon,  Routing/ 
Relmb.  dating 
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HARDWARE: 


P225B 

Printer 


GE  225 


Com¬ 

puter 

First 

Dellv- 

ery- 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

<»') 

Internal  Storage 

External  Storage 

Peripheral  Device! 

Card  Reader /Punch 

l 

Printer 

Mag  Tapes 

Disk 

No. 

Mag 

Tapes 

Trans. 

Rate 

No. 

Disks 

Trans. 

Rate 

Char. 

Ca¬ 

pacity 

Ac¬ 

cess 

Time 

(ms) 

No. 

Read 

Speed 

(cards/ 

min) 

No. 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

(1pm) 

Cycle 

Time 

(a*) 

Word 

Sire 

(bits) 

Word 

Ca¬ 

pacity 

GE 

225 

1/61 

Word 

36 

18 

20 

4,096 

3 

15K  to 
60K 

1 

62.5 

28M 

180 

1 

400 

1 

100 

1 

900 

Comment:  At  Travis  AFB  there  are  two  hardware  configurations  to  handle  an  unusually 
heavy  workload  and  at  Scott  AFB  an  extra  core  memory  module  was  added 
to  facilitate  development  programming. 


63 


GE/BSS  Sheet  5  of  7 


SOFTWARE:  Software  for  the  GE  225  consisted  of  a  GAP  assembler,  program  diagnostics, 
and  utility  routines.  The  software  was  delivered  by  GE  with  the  equipment  in  early  1962. 

Comment:  The  software  performed  well  and  has  required  little  modification  or  correction. 
One  exception  was  the  routine  which  randomly  accessed  the  disk  file  and  which  required  con¬ 
siderable  reprogramming.  It  was  felt  by  the  developers  that  the  software  contributed  signifi¬ 
cantly  to  system  development. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  GE/BSS  proposal  called  for  all  program¬ 
ming  to  be  done  exclusively  by  GE  programmers  with  technical  direction  from  Air  Force 
system  analysts.  The  development  approach  adopted  was  to  begin  work  on  the  most  critical 
aspects  of  the  system  first,  solve  them,  and  then  work  on  the  next  most  important  areas  of 
the  system.  This  resulted  in  some  unnecessary  redesign  work.  The  technical  effort  suffered 
due  to  some  design  shortcomings,  resulting  from  an  overly  optimistic  technical  estimation  by 
GE  and  the  Air  Force  system  analysts  and  an  apparently  arbitrary  and  short  USAF  schedule. 
Air  Force  and  Civil  Service  programmers  were  added  when  it  became  apparent  that  the 
number  of  GE  programmers  was  inadequate.  The  programs  were  all  written  in  GE  assembly 
language,  GAP.  Each  function  was  divided  into  subprogram  segments  of  approximately  1,000 
words  each  because  of  limited  core  space.  The  posting  programs  were  written  almost  entirely 
without  benefit  of  GE  software.  The  programmers  operated  the  computer  themselves  during 
the  six  months  checkout  period,  getting  4  to  5  short  test  runs  on  the  24-hours-per-day  con¬ 
tinually  operating  computer.  The  criteria  for  the  system  test  were  specified  by  the  supply 
analysts.  During  development  a  thorough  documentation  file  was  maintained  of  each  program* s 
interaction  with  its  environment.  Proposed  design  features,  changes  to  programs,  additional 
requirements,  and  detected  conflicts  were  documented  in  an  internal  document  series  known 
as  Program  Information  Letters  (PIL).  This  was  an  effective  programming  control  during 
the  development  period  and  has  been  praised  by  the  technical  staff  involved.  Daily  progress 
reports  from  the  programmers  were  collected  and  analyzed. 

Comment:  Another  cause  for  schedule  slippage  was  the  inclusion  of  additional  requirements, 

such  as  MILSTRIP,  which  required  redesign  and  additional  coding.  A  frozen  set  of  specifica¬ 
tions  would  have  significantly  aided  the  development  phase. 


FILE  CONVERSION:  The  data  base  to  be  employed  in  the  GE  225  system  was  essentially  the  same 
as  that  used  on  the  IBM  7070  system  at  Charleston  AFB  except  for  differences  in  format.  The 
conversion  was  done  by  special  programs  written  for  the  IBM  7070  which  dumped  the  file  onto 
magnetic  tape  and  punched  cards  in  a  format  acceptable  as  input  to  the  GE  225.  Approximately 
200,000  records  of  about  100  characters  each  were  converted.  Three  weeks  were  required 
to  complete  the  down-loading  of  the  IBM  7070  and  up-loading  of  the  GE  225.  The  system 
data  were  audited  before  and  after  the  loadings  to  verify  the  conversion. 
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DOCUMENT  A  I  ION:  At  the  completion  of  development  (December  1962),  the  system  documen¬ 
tation  was  produced:  System  Requirements  (AF  67-1),  Program  Description  (MM  67-4)  and 
User's  Manual  (MM  171-14). 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Supply 

Of  College 

Development 

Manager 

16 

6 

9.0 

8.0 

3.5 

Analyst 

6 

8 

5.0 

12.0 

Unknown 

Programmer 

7 

24 

4.0 

3.5 

Unknown 

Operations 

Manager 

1 

1 

4.0 

1.0 

Unknown 

Operator 

3 

7 

5.0 

3.0 

OPERATIONS:  The  computer  operation  is  staffed  at  Scott  AFB  as  required  by  workload.  It  op- 
erates  as  a  closed  shop.  GE/BSS  is  the  only  application  on  the  GE  225  computer.  A  monthly 
schedule  is  utilized  by  the  operational  sites  with  the  allowance  of  priority  runs  at  any  time. 
Comment:  All  development  and  maintenance  of  GE/BSS  is  performed  at  Scott  AFB.  The  average 
production  time  is  312  hours/month  for  the  operational  sites,  excluding  Scott  AFB,  with  a  maxi¬ 
mum  of  488  hours/month.  Machine  maintenance  time  is  large  (15  percent). 


APPLICATION  PROGRAM  MAINTENANCE:  All  program  modifications  and  improvements  are 
done  at  Scott  aFb .  Other  site  programmers  are  used  exclusively  to  gather  data  pertaining  to 
program  errors  and  to  install  program  changes.  The  operational  programs  have  required 
little  maintenance  or  modification. 

Comment:  The  small  requirement  for  program  maintenance  probably  arises  from  the  fact 
that  the  system  has  been  operational  for  a  relatively  long  period  of  time. 
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BENEFITS:  Proposed:  GE/BSS  was  proposed  to  provide  increased  management  control,  re¬ 
duction  of  supply  manpower,  and  more  timely  fulfillment  of  maintenance  requests  in  the 
Military  Airlift  Command.  The  concept  of  an  automated  supply  system  had  been  demonstrated 
through  a  pilot  automation  effort  on  the  IBM  7070  at  Charleston  AFB. 

Actual:  GE/BSS  provided  increased  management  control  and  more  timely  fulfillment  of  main¬ 
tenance  requests. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev.) 

Proposed:  55  O 

Actual:  375  ■■■■■■ 

Comment:  It  wii  felt  by  the  developers  that  the  schedule  imposed  on  the 
programming  group  by  Hq.  USAF  was  highly  optimistic  and  apparently 
arbitrarily  short.  This  unrealistic  schedule  led  to  a  poorly  designed 
system  that  required  some  unnecessary  redesign  work.  Air  Force  and 
civil  service  programmers  were  added  to  the  development  effort  when  it 
became  apparent  that  the  number  of  GE  programmers  was  Inadequate. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  5  I -  1 

Actual:  1} 

Comment:  GE/BSS  was  decreed  operational  on  1  July  1962  by  Hq.  USAF 
directive .  Equipment  selection  was  made  In  February  1962.  Program 
checkout  was  begun  in  April  1962.  Insufficient  manpower  and  Inclusion 
of  new  requirements,  such  as  MILSTRJP,  during  the  development  delayed 
system  operation  to  December  1962. 


Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 
Proposed:  Unk  CZ 


Actual:  212,000  ■■■■■ 

Comment:  The  checkout  computer  was  in  constant  24-hour  use  for 
6  months  of  the  period  April  to  December  1962.  It  was  felt  by  the  de¬ 
velopers  that  the  supplied  software  contributed  significantly  to  system 
development.  An  approximate  total  of  4,512  hours  was  used  for  pro¬ 
gram  checkout. 


Houra/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  Unk  CZ 


Actual:  176 

Comment:  The  actual  number  reflects  usage  on  the  GE  225  during  June  1965 
at  &cott  AFB.  The  six  operational  GE/BSS  Installations,  excluding  Scott 
AFB,  averaged  316  hours.  Maximum  usage  was  488  hours  at  Travis  AFB. 


FUTURE  PLANS:  This  system  is  currently  being  phased  out.  All  base  supply  functions 
are  being  transferred  to  the  AF  standard  base  supply  system  on  the  UNIVAC  1050-11. 


Houra/Month  of  Hardware  Use  for  Program  Maintenance  (Qp.) 
Proposed:  Unk  CZ 

Actual:  75  ■■■■■■■■■■ 

Comment:  The  actual  number  reflects  usage  on  the  GE  225  during  June 
1965  at  Scott  AFB.  AUGE/BSS  program  maintenance  la  done  at  Scott  AFB, 
Field  program  maintenance  activity  at  the  other  operational  sites  is  con¬ 
cerned  only  with  the  collection  of  program  error  data  to  send  to  Scott  AFB 
and  the  Installation  of  corrections  from  Scott  AFB. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  5  i  "H 

Actual:  8 

Comment:  The  actual  number  of  operators  at  Scott  AFB  Is  6.  The  other 
6  ope  rational  sites  average  8  operators,  with  a  maximum  of  12  at 
Travis  AFB. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  3  [  1 

4  ■HHHHHi 

Comment:  There  are  programmers  at  the  operational  sites,  other  than  at 
Scott  AFB  shown  here,  but  they  are  used  exclusively  to  collect  program 
error  data  to  send  to  Scott  AFB  and  Install  corrections.  There  are  two 
programmers  at  each  operational  site  except  Travis  and  McGuire  AFB'e, 
which  have  three  programmers  each. 

Dollars /Month  of  Hardware  Coat  (Op.) 

Proposed:  9,400  i  , 

Actual:  9.400  ■■■■■ 

Comment:  This  amount  is  the  basic  rental  charge  per  month  for  all 
operational  sites  except  Travis  AFB. 
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SYSTEM:  Global  Weather  Central--GWC  (IBM  7094  Mod  I) 


DATA  SYSTEM  DESIGNATOR:  L001 


DATA  COLLECTION  DATE:  April  1966 


Contact  for  Additional  Information 

3rd  Weather  Wing 

Offut  Air  Force  Base 

Omaha,  Nebraska 

Development 

SAC  Headquarters 

Offut  Air  Force  Base 

Nebraska 

Maintenance 

SAC  Headquarters 

Offut  Air  Force  Base 

Nebraska 

Pilot  Installation 

None 

First  Operational  Installation 

SAC  Headquarters 

Offut  Air  Force  Base 

Nebraska 

Number  of  Operational  Installations 

1 

FUNCTION:  The  user  of  GWC  is  the  3rd  Weather  Wing--Air  Weather  Service  of  the  Military 
Airlift  Command.  The  mission  of  the  user  is  to  support  the  Strategic  Air  Command  and 
classified  military  activities  with  scheduled  and  tailored  weather  products.  GWC  functions 
as  an  operational  and  intelligence  system  to  produce  weather  products  such  as  analyses, 
prognoses,  and  forecasts  for  dissemination  to  supported  units  throughout  the  continental 
United  States  and  overseas.  Teletype  information  containing  observations  of  weather  con¬ 
ditions  at  the  earth's  surface  and  at  various  altitudes  is  input  to  GWC  and  the  data  are  analyzed 
and  correlated  with  previous  weather  conditions  to  prepare  the  weather  products. 


ORGANIZATION: 


(Operator)  (Dovalopor)  (Dovaiopor)  (Dovoiopor) 
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HISTORY:  The  GWC  was  developed  in  response  to  ever-increasing  weather  requirements  being 
levied  on  the  manual  weather  prediction  and  analysis  capability  of  the  3rd  Weather  Wing.  The 
initial  system  design  was  based  on  certain  programs  operating  on  the  SAC  IBM  704  and  on  a 
system  developed  by  the  Joint  Numeric  Weather  Prediction  Unit  (JNWPU)  at  Suitland,  Maryland. 
Initially,  paper  tape  from  teletype  was  used  as  the  primary  input  source  of  observation  data. 

The  basic  system  was  subsequently  modified  substantially  by  changing  forecasting  and  analysis 
models,  adding  new  products,  upgrading  the  IBM  7090  to  an  IBM  7094  Mod  I,  installing  an  ADX 
ITT  7300  communication  computer,  and  adding  another  IBM  7094  Mod  I  computer. 

The  development  personnel  for  the  GWC  system  were  weather  specialists  with  a  very  high 
average  educational  level,  cross-trained  to  utilize  computer  skills.  This  approach  was 
adopted  because  of  difficulty  in  obtaining  data  processing  personnel  and  because  of  the  com¬ 
plexity  of  the  weather  application.  The  basic  plan  for  system  implementation  was  to  replace 
manually  generated  weather  products  with  the  automatically  generated  products  only  after  the 
automatic  system  had  been  fully  verified.  This  approach  enabled  the  system  to  be  developed 
in  a  time-phased  manner. 

The  development  activity  was  performed  primarily  by  the  Directorate  of  Scientific  Services 
and  the  Automation  Division.  The  Directorate  of  Scientific  Services  was  responsible  for  the 
formulation  of  the  basic  models  used  in  the  system.  In  many  cases,  personnel  of  the  Di¬ 
rectorate  wrote  programs  to  verify  the  concepts  and  models  which  they  had  developed.  The 
actual  production  programs  were  written  by  personnel  in  the  Automation  Division.  No  clear 
distinction  between  programmer  and  system  analyst  was  made,  since  virtually  all  people 
doing  programming  had  a  meteorology  background. 

GWC  is  housed  in  two  separate  facilities  approximately  one  mile  apart.  One  of  these 
facilities  is  in  a  hardened  underground  area  resulting  in  materially  increased  costs  for  this 
facility.  Due  to  the  distance  between  the  two  sites,  an  IBM  7711  data  transmission  unit  is 
necessary  which  would  not  have  been  required  for  a  single  facility.  The  estimated  facility 
preparations  costs  for  the  non-hardened  installation  were  $100,000. 

A  large  portion  of  the  GWC  output  is  unclassified.  During  the  development  and  production 
of  highly  classified  outputs  the  environment  is  so  secure  that  many  programmers  involved  in 
checkout  of  less  highly  classified  projects  are  denied  access  to  the  computer  room,  resulting 
in  less  efficient  checkout  than  could  have  been  accomplished  otherwise. 
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DESCRIPTION:  GWC  input  containing  observations  of  weather  conditions  at  the  earth* s  surface 
and  at  various  altitudes  in  the  upper  air  is  received  via  teletype.  All  input  except  for  relevant 
observations  is  stripped  off  prior  to  further  analysis.  About  50  percent  of  the  data  monitored 
over  the  teletype  wires  is  not  useful  to  GWC.  The  observations  are  then  analyzed  and  correlated 
with  previous  weather  conditions  and  forecasts  are  prepared.  Analysis  and  forecast  runs  are 
made  four  times  daily.  The  runs  at  0600  and  1800  hours  are  not  transmitted  to  the  field  but  are 
analyzed  in-house  and  used  in  the  production  runs  at  0000  and  1200  hours. 


20  TTY  Lines 
With  Worldwide 
Weather  Observ- 
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WORKLOAD: 


DATA  BASE 

Char.  In  Data  Baaa: 

3.790,000 

Percent  of  Char,  on  D/A  Storage: 

NA 

Millisecond*  of  Access  Time  for  D/A: 

NA 

No.  of  Data  Base  Record  Types: 

7 

No.  of  Data  Base  Records: 

Unk 

Percent  Growth  Rate  /Mo. : 

Unk 

Char.  /Mo.  of  Update  Input: 

Unk 

PROCESSING 

FUNCTIONS 


Char.  /Mo.  of  Input 

Volume  t 

715.400,000 

No.  of  Input  Trans- 

action  Types: 

No.  of  Input 

Data  Fields: 

418 

Percent  of  Input 

Rejects: 

4.5 

Kay 


la  .$  r  t  f  I  \i  ] 

is  cl  3  3,  5  S  &&  5 


100% 
90 
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70 

60 

50 

40 

30 

20 
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0% 
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$1 

Ax 


A 


00  00  00  00 


rijL 

tin 


OUTPUTS 


Al 


Total  Source  Instruction* 
Total  Object  Inetructlona: 
Hri./Mo.  of  Application 
Production; 


Base  Computar(a) 

99.790 
124.200 


Paripharal 
Computer!  a) 

Unk 

Unk 


Cher. /Mo.  of  Out¬ 

put  Volume: 

S98.000.uuu 

No.  of  Output 

Formats: 

121 

Response  Tim* 

(seconds): 

NA 

Com- 
pit  -  r 

First 

Dellv- 

sry 

Mo/Yr 

Word 

or 

Chsr. 

Msch. 

Add 

Tims 

(u*) 

Interne)  Storage 

External 

Storage 

Peripheral  Devices 

Card  Reader /Punch 

Printer 

PT  Reeder 

PT  Punch 

Cycle 

Tims 

(U*l 

Word/ 

Chsr. 

Six* 

(bits) 

Word/ 

Chsr. 

Ca¬ 

pacity 

No. 

Meg 

Tepes 

Trens. 

Kate 

No. 

Read 
Spe  ed 
(cards/ 
min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

Upm) 

No. 

Reed 

Speed 

(char./ 

see) 

No. 

Punch 

Spesd 

(char./ 

••c) 

IBM 

7094 

9/62 

Word 

4 

2 

36 

32K 

2*729 IV 

if  "7  mi 

22.5K- 

ISK- 
41. 6K 

1  • 
711 

2S0 

too 

1- 

716 

ISO 

None 

... 

None 

... 

IBM 

7094 

9/62 

Word 

4 

2 

36 

32K 

12*72911 

1SK- 
41. 6K 

l- 

711 

2S0 

100 

1- 

716 

ISO 

None 

... 

None 

... 

IBM 

1401 

9/60 

Cher. 

230 

11.  s 

6 

8K 

1*729  U 

ISK- 
41. 6K 

1  - 

1402 

800 

2S0 

1- 

1403-2 

600 

1- 

1903 

soo 

1- 

1902 

ISO 

IBM 

1401 

9/60 

Cher. 

230 

11.  s 

6 

BK 

2-729 U 

ISK* 
41. 6K 

I  - 

1402 

800 

2S0 

1  - 

403*2 

600 

None 

... 

None 

... 

ITT 

7300 

unk 

Word 

10 

S 

18 

32K 

2-7320 

ISK 

None 

None 

— 

Con¬ 

sole 

400 

Con¬ 

sole 

20 

Comment:  Other  peripheral  devices  include  a  Benson  Lehner  Data 
Plotter  and  a  CV  1357  Converter. 


70 


GWC  Sheet  5  of  7 


SOFTWARE:  The  entire  IBM- supplied  software  packages  for  the  IBM  7094  are  available  to  GWC 
as  is  the  SHARE  library.  GWC  has  been  using  the  FORTRAN  monitor  system  with  the 
FORTRAN  II  compiler,  FAP  assembler,  and  a  standard  IBM-supplied  library  including  some 
special  GWC  routines.  GWC  has  also  been  using  a  GWC-developed  control  program  AUTO  and 
the  IBM  IBSYS  executive  system  in  conjunction  with  FORTRAN  IV.  The  IBSYS  executive  in¬ 
cludes  a  MAP  assembler,  a  COBOL  compiler,  Report  Program  Generator  (RPG),  and  a  linkage 
editor. 

Comment:  The  FORTRAN  monitor  system  and  the  IBSYS  executive  system  are  used  for  program 
development  but  not  for  production  runs.  All  production  is  run  under  AUTO,  the  GWC- 
developed  control  program,  which  requires  considerably  less  core  than  either  the  FORTRAN 
monitor  system  or  IBSYS.  Little  of  the  IBSYS  executive’s  capability  is  being  used.  Virtually 
none  of  the  SHARE  library  routines  are  being  used  at  this  time,  although  some  were  used  during 
the  early  development  stages. 

Maintenance  of  the  IBM- supplied  software  requires  two  people  on  a  full-time  basis,  one 
supplied  by  IBM  and  the  other  by  GWC.  GWC  is  very  happy  with  the  support  received  from 
IBM  (on-site  and  from  IBM  headquarters)  and  feels  that  this  support  tremendously  enhances 
the  maintenance  of  the  support  software. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  GWC  development  activity  was  performed 
by  the  Directorate  of  Scientific  Services  and  the  Automation  Division  of  the  3rd  Weather  Wing. 
The  Directorate  of  Scientific  Services  was  responsible  for  formulation  and  verification  of  the 
models  and  computational  techniques  used  in  GWC,  while  the  Automation  Division  was  respon¬ 
sible  for  programming  the  production  programs,  integrating  these  programs  into  the  GWC 
system  and  verification  of  system  operation.  A  clear  distinction  between  analyst  and  pro¬ 
grammer  was  not  made  in  the  GWC  system,  since  virtually  all  the  people  doing  programming 
had  a  strong  meteorology  background.  Development  effort  from  other  numeric  weather  proj¬ 
ects  such  as  the  Joint  Numeric  Weather  Production  Unit  was  used  whenever  possible.  The 
programs  were  coded  in  FORTRAN  II  and  FAP  assembly  language*  The  GWC  system  is  com¬ 
prised  of  86  separate  programs,  grouped  together  as  8  packages.  Each  package  is  run  as  a  sub¬ 
system  generating  specific  output  products.  The  program  testing  was  done  using  the  FORTRAN 
monitor  system.  The  development  of  the  system  was  on  a  time-phased  basis  such  that  per¬ 
sonnel  freed  from  the  manual  preparation  of  products  could  be  utilized  in  further  system  de¬ 
velopment,  The  time  phasing  also  allowed  thorough  verification  of  new  products  prior  to  op¬ 
erational  use.  Quarterly  progress  reports  were  submitted  during  development. 


FILE  CONVERSION:  No  file  conversion  was  involved  in  GWC  development. 
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DOCUMENTATION:  3WWM  105-12  describes  the  centrally  prepared  products  that  are  transmitted  to 
field  units.  It  provides  information  on  the  use  of  the  products  and  verification  information  on  selected 
forecast  products.  Documentation  of  the  inter  system  workings  and  individual  programs  is  generally 
inadequate.  No  formalized  documents  giving  system  flow  charts,  program  flow  charts,  or  narrative 
program  descriptions  were  found.  Documentation  of  program  operational  procedures  is  complete 
and  is  kept  on  cards  for  easy  maintenance. 

personnel!  " 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Weather 

Of  College 

Development 

Manager 

6 

6 

5.0 

13.5 

6.5 

Analyst 

25 

25 

2.5 

13.0 

7.0 

Programmer 

28 

28 

2.5 

9.5 

Unknown 

Operations 

Manager 

18 

18 

2.0 

11.0 

3.0 

Operator 

73 

73 

1.5 

7.0 

OPERATIONS:  The  computer  operation  is  staffed  24  hours  a  day,  7  days  a  week.  It  operates  as 
a  closed  shop.  The  GWC  application  shares  both  IBM  7094/1401  computer  systems.  The  two 
IBM  7094/1401  installations  are  located  at  different  sites,  approximately  1  mile  apart,  neces¬ 
sitating  transmission  between  sites  of  information  via  the  IBM  7711.  The  IBM  7094/1401  (A) 
system  is  owned,  while  the  (B)  system  is  rented. 

Comment:  An  excellent  daily  master  schedule  is  strictly  followed  to  utilize  the  owned  computers 
as  much  as  possible  and  to  obtain  the  most  updated  input  before  transmitting  weather  products  at 
fixed  intervals.  Idle  time  on  the  leased  computer  is  nonchargeable  by  the  manufacturer. 

SchS  Ml 


Prop  (GWC 
•pp)  K>  hr.  4% 


Pr.p  (GWC 
•pp)  I  hr  1% 

Pro,  Dr*  *  Ml 
(GWC  .pp)  14  hr. 
Pr»4  (.11  olh.  r 
•pp.)  44  hr*  1% 


Prod  ICiWC 
•pp)  I  TO  hr.  iPfc 
Pro,  l>»v  4  Ml 
(GWC  app)  )h  hr.  1% 
Prod  (all  oth.r 
•pp.)  <4  hr.  4% 


APPLICATION  PROGRAM  MAINTENANCE:  Current  programming  activity  involves  59  per¬ 
sonnel  and  is  divided  into  4  areas:  (1)  new  product  programming,  19  percent;  (2)  program  im¬ 
provements,  60  percent;  (3)  program  corrections,  14  percent;  and  (4)  program  and/or  product 
deletions,  7  percent.  Program  improvements  include  optimization  of  running  time,  tape  manip¬ 
ulation  changes  for  more  efficient  production  flow,  and  improved  data  processing  schemes.  The 
Program  Applications  Branch  is  responsible  for  pre-production  testing  of  all  programs  prior  to 
their  release  to  production. 

Comment:  Program  development  as  well  as  maintenance  is  a  continuing  and  significant  aspect 
of  GWC.  Due  to  the  diversity  and  lack  of  control  of  weather  observation  input  formats,  program 
maintenance  is  constantly  required  to  comply  with  changes  in  this  area.  Increasing  require¬ 
ments  in  the  field  of  weather  analysis  and  forecasting  have  caused  improvements  in  old  weather 
models  and  concepts  and  the  development  of  new  ones.  Thus,  development  programming  activ¬ 
ity  is  always  in  progress  with  approximately  the  same  number  of  people  involved  in  develop¬ 
ment  now  as  were  involved  during  the  original  system  development. 
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^ ENEFITSs  Proposed:  The  GWC  was  proposed  to  provide  weather  information,  such  as  fore¬ 
cast,  analyses,  and  special  reports  to  the  Strategic  Air  Command  and  other  AF  users.  Prior 
to  development  of  the  GWC,  these  products  were  manually  produced.  The  manual  processing 
of  weather  data  was  rapidly  becoming  unfeasible  by  I960.  New  weather  products  including  fore¬ 
casts  at  high  altitudes  were  required.  In  addition,  requirements  existed  for  increased  frequency 
of  weather  reports. 

Actual:  The  GWC  has  evolved  over  a  number  of  years  and  is  currently  providing  automated 
weather  products  twice  daily.  A  number  of  new  weather  products  and  items  or  equipment  have 
been  added  since  the  initial  operational  capability.  Weather  products  requirements  are  con¬ 
tinually  increasing,  requiring  plans  to  be  developed  for  new  programs  and  equipment. 


COST  FACTORS: 


M»n-Month«  of  Development  Effort  (Dev.) 

Proposed:  Unk  CZ 

Actual:  4.404 

Comment:  No  formal  proposal  such  as  a  DAP  was  prepared  for  the 
C WC.  Tl»e  GWC  ADPS  developed  from  ever-increasing  weather  re¬ 
quirements,  and  hence,  proposal  activities  are  to  be  found  throughout 
the  GWC  development  and  operation.  A  substantial  portion  of  the  de¬ 
velopment  effort  to  date,  as  represented  here,  may  be  regarded  as 
program  maintenance  in  the  continual  development  of  the  GWC, 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  Unk  t~7 

Actual:  2 1  ■■■■■ 

Comment:  The  Initial  development  effort  of  the  GWC  was  considered  to 
Have  begun  in  January  I960  and  ended  in  October  1961,  as  represented 
here,  when  it  became  operational.  New  programs,  however,  are  con¬ 
tinually  being  developed  to  meet  the  ever-increasing  needs  of  AF 
weather-  users. 


Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 
Proposed:  Unk  Q 

Actual:  Unk  W 

Comment:  No  records  were  kept  for  computer  hours  used  for  GWC 
program  checkout. 

Hours  /Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  Unk  CZ 

Actual:  500 

Comment  The  actual  number  reflects  usage  during  March  1966  on  both 
UTKTTff^T  I  computers.  A  total  of  1,040  hours  was  used  for  GWC  appli¬ 
cation  production  on  the  two  IBM  1401  computers  and  the  ITT  7300  ADX. 


Hours/Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 
Proposed:  Unk  CZ 

Actual:  140  ■§■■■■■■■■ 

Comment:  The  actual  number  reflects  usage  during  March  1966  on  both 
IBM  7094  I  computers.  A  total  of  37  hours  was  used  for  GWC  program 
maintenance  on  the  two  IBM  1401  computers  and  the  ITT  7300  ADX. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  44  1  1 

Actual:  91  ■■■■■■■■■ 

Comment:  The  proposed  number,  consisting  of  12  operators  and  32  data 
preparation  personnel,  came  from  an  anticipated  manpower  projection 
established  in  January  I960.  The  actual  number  of  personnel  consists  of 
73  operators  and  16  managers. 

Number  of  Program  Maintenance  Personnel  (Op.) 
Proposed:  41  1  I 

Actual:  59 

Comment:  The  proposed  number,  consisting  of  1  manager,  26  analysts, 
and  12  programmers,  came  from  an  anticipated  manpower  projection 
established  in  January  I960.  The  ac  ual  number  consists  of  6  managers, 
25  analysis,  and  26  programmers. 

Dollars/Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  CZ 

Actual:  240,297 
Comment:  None. 


FUTURE  PLANS:  Experience  at  the  GWC  has  been  one  of  continually  adding  programs  and 
equipment  to  meet  ever-increasing  needs  of  AF  weather  users.  GWC  personnel  currently 
estimate  that  by  FY  1968  the  equivalent  of  five  IBM  7094  Mod  I  computers  will  be  required. 
To  meet  these  increasing  requirements,  a  DAP  is  presently  being  prepared  outlining  the 
anticipated  future  requirements.  The  proposed  system  is  to  include  such  state-of-the-art 
features  as  multiprogramming,  multiprocessing,  large-scale  direct  access  memory,  and 
on-line  consoles. 

Because  of  the  huge  investment  in  programming  (99  percent  of  the  programs  are  in 
IBM  7094  machine  language)  it  is  felt  that  the  new  computer  system  must  have  the  capability 
of  emulating  the  IBM  7094.  Other  functional  refinements  desired  include  the  use  of  a  finer 
mesh  grid  to  improve  model  accuracy  and  the  use  of  satellite  and  aerospace  data. 
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SYSTEM:  Merged  Accountability  and  Fund  Reporting  III- -MAFR  (RCA  501/301) 


DATA  SYSTEM  DESIGNATOR:  H053  and  H055 
DATA  COLLECTION  DATE:  May  1966 


Contact  for  Additional  Information 

Directorate  of  Data  Automation 

Air  Force  Accounting  and  Finance  Center 
3800  York  Street 

Denver,  Colorado 

Development 

Air  Force  Accounting  and  Finance  Center 
Denver,  Colorado 

Maintenance 

Air  Force  Accounting  and  Finance  Center 
Denver,  Colorado 

Pilot  Installation 

None 

First  Operational  Installation 

Air  Force  Accounting  and  Finance  Center 
Denver,  Colorado 

Number  of  Operational  Installations 

1 

FUNCTION:  The  immediate  user  of  MAFR  ILL  is  the  Directorate  of  Central  Accounting  of  the 
Air  Force  Accounting  and  Finance  Center.  Ultimate  and  prime  users  of  MAFR  III  are  the 
U.S.  Treasury  Department  and  the  Air  Force  Director  of  the  Budget.  The  mission  of  the 
prime  users  is  to  monitor  Air  Force  expenditures  and  maintain  an  accountability  of  all  Air 
Force  Funds.  The  Treasury  Department,  of  course,  has  other  missions  beyond  Air  Force 
accountability.  MAFR  III  functions  as  a  management  support  system  to  maintain  accountability 
of  cash  expenditures  and  status  of  funds  allocated  for  specific  materials  or  services  and 
consolidates  the  data  in  monthly  reports. 


ORGANIZATION: 


(U.er) 


74 


MAFR  Sheet  2  of  7 


HISTORY:  Certain  insufficiencies  in  the  MAFR  II  System  necessitated  a  major  reengineering  of 
the  system  in  order  to  generate  the  products  required  by  the  user.  The  primary  insufficiency 
was  the  lack  of  ability  to  produce  reports  on  Status  of  Funds.  The  accounting  categories  for 
Status  of  Funds  for  MAFR  III  are  not  the  same  as  those  used  in  MAFR  II,  which  necessitated  a 
complete  system  redesign  for  MAFR  III.  The  concept  for  MAFR  HI  was  approved  by  Head¬ 
quarters,  Air  Force  Accounting  and  Finance  Center  (AFAFC)  with  subsequent  approval  by 
Headquarters  USAF.  The  project  started  in  December  1962  and  was  operational  in  July  1963. 

A  planned  schedule  of  events  during  development  was  prepared  and  coincided  with  the  actual 
development  schedule. 

The  reengineering  of  MAFR  II  to  MAFR  HI  was  a  joint  effort  of  the  Directorate  of 
Central  Accounting  and  the  Directorate  of  Data  Automation  at  AFAFC.  Specific  tasks  were 
assigned  to  each  with  continuous  coordination  of  activities. 

In  general,  the  Directorate  of  Central  Accounting  was  responsible  for  developing  the 
accounting  system  concept,  input  formats,  edit  and  balance  criteria,  output  formats,  and 
providing  system  test  data. 

The  Directorate  of  Data  Automation  was  responsible  for  developing  the  EDP  system 
concept  and  specifications,  programming  and  program  documentation,  and  testing  and 
debugging. 

A  joint  responsibility  of  the  two  directorates  was  the  implementation  plan,  developing 
operational  schedules,  reviewing  systems,  test  output,  establishing  "live"  operations,  and 
monitoring  initial  "live”  production  for  conformance  to  desired  output. 

Since  MAFR  III  became  initially  operational,  63  new  programs  have  been  added  to  the 
original  95  to  add  refinements  and  to  satisfy  additional  customer  requirements. 

A  variety  of  documents  were  produced  during  the  development  of  the  MAFR  III 
system.  MAFR  HI  is  generally  a  thoroughly  documented  system,  and  strong  management 
control  resulted  in  the  proper  flow  and  distribution  of  the  generated  documentation. 


SCHEDULE: 
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DESCRIPTION:  MAFR  III  is  an  AF  central  accounting  system  for  maintaining  accountability 
“of  cash  expenditures  and  status  of  funds  allocated  for  specific  materials  or  services.  MAFR 
III  enables  AFAFC  to  act  as  a  clearing  house  for  vouchers  paid  by  one  Accounting  and  Finance 
Office  (AFO)  for  another  AFO.  Each  AFO  forwards  the  vouchers  paid  for  other  AFO's  to 
AFAFC  along  with  vouchers  for  its  own  payments.  AFAFC  then  forwards  the  "for  others'1 
vouchers  to  the  AFO  for  whom  they  were  paid.  In  the  process  of  receiving  and  distributing 
these  reports,  MAFR  III  maintains  a  complete  Air  Force-wide  accountability  which  is  con¬ 
solidated  on  a  monthly  basis  into  the  Status  of  Funds  Report  and  Cash  Expenditure  Report, 
which  are  sent  to  Hq.  ,  USAF,  and  the  Treasury  Department,  respectively. 


no  <>HAt 


to  1  rfirir,  Otparlimnl 


l»*  Appropriate  At  O'* 


In  Major  Air  Commanda 
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WORKLOAD: 


DATA.  BASE 


Char.  In  Data  Base: 

28.550.000 

Percent  of  Char,  on  D/A  Storage: 

NA 

Milliseconds  of  Access  Tim*  for  D/A: 

NA 

No.  of  Data  Base  Record  Types: 

11 

No.  of  Data  Base  Records: 

285.000 

Percent  Growth  Rate  /Mo. : 

Unk 

Char.  /Mo.  of  Update  Input: 

18.880.000 

PROCESSING 

FUNCTIONS 


Char.  /Mo.  of  Input 

Volume: 

18.880.000 

No.  of  Input  Trans* 

action  Types: 

85 

No.  of  Input 

Data  Fields: 

81 

Percent  of  Input 

Rejects: 

±1 

f 


K.y 


it  ft  f  S  .  1 
IS  cl  3  II  S  53  8 


100% 

90 

80 

70 

80 

SO 

40 

30 

20 

10 

0% 


OUTPUTS 


ml 


JhL 


Total  Source  Instruction* 
Total  Objact  Instruction*: 
Hr*. /Mo.  of  Application 
Production: 


Baso  Compute  r(a) 

25,000 

100.200 

148 


Perlphe  ral 
Compute  r(e) 

ISO 

719 


Char. /Mo.  of  Out 
put  Volume: 

No.  of  Output 
Formats:  158 

Response  Time 
(seconds):  NA 


401.800.000 


HARDWARE: 


RCA  501-1 


Console 

1 

Coneole 

1 

- ! - 

RCA  561-3 

Hi-Speed 

Storage 

RCA  503 

Central 

Processing 

Unit 

RCA  547-6 

Tape 

Switch 

Control 

"I 

1 

1 

RCA  561-3 

Hi-Speed 

Storage 

RCA  503 

Central 

Processing 

Unit 

RCA  547-6 

Tape 

Switch 

Control 

RCA  501-2 


RCA  369-1 

Card  Reader/ 
Punch  Control 

RCA  330 

Card 

Reader/ Punch 

RCA  316-1 

RCA  333 

On-Line  Printer 

On-Line 

Control 

Printer 

RCA  316-2 

RCA  333 

On-Line 

On-Line 

Printer  Control 

Printer 

RCA  393-1 

RCA  390  IBM 

581 

729  Tape 

Adapter 

Control 

RCA  311  Paper 

RCA  322  Paper 

Tape  Reader 

Tape 

Control 

Reader 

RCA  301 


Com¬ 

puter 

First 

Dellv- 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal  Storage 

External 

Storage 

Peripheral  Devices 

Card  Reader /Punch 

Printer 

PT  Read /Punch 

No. 

Read 

Speed 

(cards/ 

min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

(1pm) 

No. 

Speed 

(char./ 

sec) 

Speed 
(char.  / 
sec) 

Cycle 

Time 

(us) 

Char. 

Sice 

(bits) 

Char. 

Ca¬ 

pacity 

No. 

Mag 

Tapes 

Trans. 

Rate 

RCA 

501 

11/59 

Char. 

360 

12 

6 

32,768 

11- 

581 

33K  to 
66K 

None 

— 

... 

None 

... 

... 

... 

... 

RCA 

501 

11/59 

Char. 

360 

12 

6 

32,768 

8- 

581 

33K  to 
66K 

None 

... 

... 

None 

... 

— 

... 

... 

RCA 

301 

2/61 

Char. 

67 

4.8 

6 

20,000 

729-11 

15K  to 
41. 6K 

I- 

330 

800 

250 

2- 

333 

1,000 

1- 
3  22 

1,000 

100 
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SOFTWARE:  Software  for  the  RCA  501's  consisted  of  the  following:  (1)  a  COBOL  compiler; 

(2)  an  EZCODE  assembler;  (3)  a  monitor  and  loader;  (4)  a  sort  and  merge  program  package; 
and  (5)  a  debugging  package. 

Comment:  Since  the  RCA  computers  had  already  been  operational  for  a  considerable  period 
of  time  prior  to  MAFR  III  development,  the  software  was  well  debugged.  The  only  exception 
to  this  was  a  sort  package. 


APPLICATION  PROGRAM  DEVELOPMENT:  A  systems  concept  document  consisting  of  flow 
charts  and  listings  oi  necessary  tasks  ior  the  operation  of  the  system  was  prepared  by  ana¬ 
lysts  from  the  Directorates  of  Central  Accounting  and  Data  Automation  within  AFAFC.  Sub¬ 
sequently,  the  Directorate  of  Central  Accounting  provided  the  accounting  system  concept, 
input  formats,  edit  and  balance  criteria,  output  formats,  and  system  test  data.  The  Di¬ 
rectorate  of  Data  Automation  provided  the  EDP  system  concept  and  specifications,  program¬ 
ming  and  program  documentation,  testing  and  debugging.  The  two  directorates  jointly  pro¬ 
vided  the  implementation  plan,  operational  schedules,  a  review  of  the  systems  test  output, 
and  the  establishment,  monitoring  and  verification  of  live  operations  and  production.  During 
checkout  of  the  COBOL  programs,  the  turnaround  time  was  approximately  24  hours.  The  sys¬ 
tem  was  designed  to  operate  on  an  existing  RCA  501  installation.  Pert  charts,  weekly  progress 
reports,  and  work  measurement  reports  were  utilized  during  development. 


FILE  CONVERSION:  File  conversion  to  MAFR  III  formats  was  an  involved  process  since  the 
file  formats  of  MAFR  III  differed  significantly  from  those  of  MAFR  II.  Special  file  conversion 
programs  were  written  to  extract  information  from  a  number  of  different  MAFR  II  files  and 
generate  the  appropriate  MAFR  III  files.  Approximately  five  man-months  of  effort  and  30 
computer  hours  were  required  to  generate  the  necessary  MAFR  III  data  base  files  prior  to 
system  operation. 
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DOCUMENTATION:  Documentation  was  produced  during  development  by  both  Central  Accounting 
and  Data  Automation.  Among  the  major  documents  are  the  following:  Accounting  Concepts, 

ADP  System  Concept,  Customer  Requirements,  System  Specification,  Program  Packages, 

Office  Instructions,  and  AF  Manuals  (a  user's  manual). 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated 
to  System 

In  ADP 

In  Accounting 

Of  College 

Development 

Manager 

2 

2 

11 

20.5 

4 

Analyst 

4 

4 

4.S 

12.5 

Unknown 

Programmer 

19 

19 

6 

6 

U  nknown 

Operations 

Manager 

I 

0.3 

Unknown 

U  nknown 

U  nknown 

Operator 

8 

8 

5.5 

Unknown 

XT 

OPERATIONS:  The  computer  operation  is  staffed  24  hours  a  day,  6  and  occasionally  7  days  a 
week.  It  operates  as  a  closed  shop.  MAFR  is  only  one  of  several  applications  run  on  the  two 
RCA  501's,  the  RCA  301,  and  the  IBM  1401  computers.  A  monthly  schedule,  broken  down  into 
a  daily  and  tentative  next-day  schedule,  is  utilized. 

Comment:  The  "Other  Time"  shown  in  the  pie  charts  is  made  up  of  machine  maintenance,  idle 
time,  machine  error  lost  time,  and  off  time. 


Off 

67  hra  9%  "S. 

Sc hd  Mt 

42  hra  6%  \ 

Prod  (MAFR 
app)  76  hra  1 1% 

Prog  Dev-4  Mt 
(MAFR  app) 

68  hra  9% 

Mach  Error  Loat  > 

26  hra  4%  \ 

Unachd  Mt  \ 

IS  hra  2% 

Idle  - - - 

24  hra  3% 

Set  Up  /j 
36  hra  5%  / 

Prod  (all 
/  other  appa) 

//■  22 5  hra  31% 

Chg  Loat  (all  / 

Prep  (all  other 

other  appa)  25  hrs  3%  / 

Chg  Loat 

•pptj  jc  nn  9Ti 

-  Prog  Dev  4  Mt 

(MAFR  app) 

7  hra  1% 

RCA  501  A 

(all  other  appa) 
87  hra  12% 

Mach  Error  Loat 
16  hr a  If 


Ch* 

Loat  (all  othar  appa) 


Ch«  Loat  (MAFR  app) 
6  hr  a  [f 


Prod  (MAFR 
app)  70  hra  0% 

Prog  Dev  *  Mt 
(MAFR  app) 

54  hra  7% 


Prod  (all  other 
appa)  116  hra  31% 


Prap  (all  othar 
appa)  I  3  hra  2% 

Prog  Dev  4  Mt  (all  other  appa) 
129  hra  18* 


Off 

49  hra  7% 
S.  hd  Mt 
31  hra  4% 
Mach  Error  Loat 
4  hra  1% 

Unachd  Mt 
15  hra  2% 
Idle 

82  hra  I  1% 

Set  Up 
28  hra  4% 

Chg  Loat  (all 
other  appa)  4  hra  1% 
Prog  Dev  *  Mt 
(all  other  appa) 
71  hra  10% 


Prod  (MAFR 
app)  84  hra  12% 

Prog  Dev  6  Mt 
(MAFR  app) 

30  hra  4% 


Prod  (all  other 
appa)  316  hra  42% 

Prep  (all  other 
appa)  16  hra  2% 


RCA  301 


Prod  (MAFR 
app)  37  hra  5% 

_  Prog  Dev  *  Mt 
(MAFR  app) 
v 7  hra  1% 

Prod  (all  other 
appa)  306  hra  40% 


Prog  Dev  6  Mt 
(all  other  appa) 
26  hra  4% 


APPLICATION  PROGRAM  MAINTENANCE:  There  are  currently  10  programmers  and  one  ana¬ 
lyst  involved  in  program  maintenance  on  MAFR  III.  Approximately  40  percent  of  these  personnel 
were  involved  in  the  development  of  MAFR  III.  Any  programming  changes  resulting  in  change 
pages  to  Customer  Requirements,  System  Specifications,  or  Supplemental  System  Specifications 
must  be  approved  by  the  Directorates  of  Central  Accounting  and  Data  Automation. 

Comment:  Program  maintenance  is  driven  by  the  constant  system  improvement  effort  and  con- 
tinual  changes  caused  by  varying  customer  requirements.  There  is  very  little  program 
correction  performed. 
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BENEFITS;  Proposed:  MAFR  III  was  to  be  a  reengineering  of  the  existing  MAFR  II  system. 
MAFR  III  was  to  operate  on  the  same  equipment  as  MAFR  II.  The  primary  objective  of  MAFR  III 
(as  opposed  to  MAFR  II)  was  to  reduce  the  undistributed  balances  so  that  distributed  balances 
could  be  used  in  current  Status  of  Funds  reports. 

Actual:  MAFR  II  successfully  reduced  undistributed  balances,  from  $250  to  $300  million  under 
MAFR  II  to  approximately  $40  million.  This  enabled  more  accurate  and  timely  reports  of 
Status  of  Funds  to  be  produced.  The  development  of  MAFR  III  was  based  on  the  improvement 
of  products  being  produced  by  MAFR  II. 


COST  FACTORS; 


Man- Month*  of  Development  Effort  (Dev.)  Hour* /Month  of  Hardware  Use  lor  Program  Maintenance 


Proposed:  Unk  CZ 

Aitual:  JO 2  ■■■■■ 

Comment :  No  formal  proposal  was  prepared  for  MAFR  III.  A  system* 
concept  was  prepared  for  MAFR  III  by  analysts  from  Data  Automation 
and  Central  Accounting  within  AF  AFC.  This  document  consisted  of 
flow  charts  and  listings  necessary  lor  the  operation  of  MAFR  III. 

Months  of  F. lapsed  Development  Time  (Dev.) 

Proposed:  7  L  1 

Actual:  “3 

Comment:  The  target  operational  date  established  in  the  system*  concept 
document  was  1  July  I ^*6 3 . 

Dollars  of  Hardware  Cost  for  Program  Checkout 
Proposed:  Unk  □ 

Actual:  73,900  ■■■■■■■■■ 

Comment:  Program  checkout  occurred  from  April  to  August  1963  on  the 
RTTa“*0T7  A  total  of  Ub  hours  was  used  for  program  and  system  checkout. 

Hours/Month  of  Hardware  Use  for  Application  Production 
Proposed:  Unk  CZ 

Actual:  14b 

Comment:  The  actual  number  reflect*  usage  during  March  1966  on  the  two 
RCA  computer*.  One  hundred  twenty-one  hours  were  used  for  MAFR 
application  production  on  tie  prrtphrral  RCA  301  and  the  IBM  1401. 


Proposed:  Unk  f~7 

Actual:  122  ■■■■■■■■ 

Comment:  The  actual  number  reflects  ussge  during  March  1966  on  the  two 
RCA  501  computers.  Thirty-seven  hours  were  used  for  MAFR  progrsm 
maintenance  on  the  peripheral  RCA  301  and  the  IDM  1401. 

Number  of  Operations  Personnel 

Proposed:  Unk  Gf 

Actual:  8.3  BHBHHBH 

Comment:  The  actual  number  of  personnel  is  prorated  from  35  people 
base<j  on  machine  hours  for  MAFR. 

Number  of  Program  Maintenance  Personnel 
Proposed:  Unk  CZ 

II 

Comment:  The  actual  number  of  personnel  represents  10  programmers 
and  1  analyst  allocated  to  MAFR  program  maintenance. 

Dolls rs /Month  of  Hardware  Cost 

Proposed:  Unk  C2 

Actual:  2*9 

Comment:  None. 


FUTURE  PLANS:  A  conversion  to  RCA  3301  computers  is  planned  to  relieve  the  overloaded 
RCA  501  computers.  The  programming  impact  of  this  conversion  will  be  minimal  since  the 
vast  majority  of  application  programs  are  written  in  COBOL.  Studies  are  being  made  to  in¬ 
clude  long-range  AF  and  DOD  objectives  which  could  result  in  major  changes  in  the  MAFR  III 
system;  however,  no  specific  plans  have  been  approved  at  this  time. 
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SYSTEM:  Air  Force  MILSTAMP  Central  Data  Collection- -MILSTAMP  (UNIVAC  1050/1107) 


DATA  SYSTEM  DESIGNATOR:  O025E 


DATA  COLLECTION  DATE;  April  1966 


Contact  for  Additional  Information 

Data  Services  Division 

Sacramento  Air  Materiel  Area 

McClellan  Air  Force  Base 

Sacramento,  California 

Development 

Sacramento  Air  Materiel  Area 

McClellan  Air  Force  Base 

California 

Maintenance 

Sacramento  Air  Materiel  Area 

McClellan  Air  Force  Base 

California 

Pilot  Installation 

None 

First  Operational  Installation 

Sacramento  Air  Materiel  Area 

McClellan  Air  Force  Base 

California 

Number  of  Operational  Installations 

1 

FUNCTION:  The  users  of  MILSTAMP  are  the  Directorate  of  Transportation,  Headquarters 
USAF;  Directorate  of  Transportation,  Headquarters  AFLC;  and  the  Directorates  of  Trans¬ 
portation  of  USAF  Air  Command.  A  common  mission  of  the  users  is  to  evaluate  military  and 
civilian  carrier  performance  by  measuring  and  establishing  standard  transit  and  hold  times. 
MILSTAMP  functions  as  a  management  support  system  to  prepare  reports  from  "in  transit" 
data  pertaining  to  worldwide  Air  Force  shipment  and  transshipment  activities  on  a  monthly 
basis  for  the  users. 


ORGANIZATION: 


(D*v«lop«r/  Operator) 
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HISTORY:  A  Data  Automation  Proposal  to  develop  the  Air  Force  MILSTAMP  Central  Data 
Collection  sybtem  was  forwarded  by  Headquarters  AFLC  to  Headquarters  USAF  in  July  1963, 
based  on  a  DOD  directive  to  implement  Military  Standard  Transportation  and  Movement  Pro¬ 
cedures  (MILSTAMP)  by  October  1963.  Approval  of  this  system  was  granted  by  Head¬ 
quarters  USAF  in  a  letter  of  13  November  1963,  which  directed  the  collection  of  MILSTAMP 
intransit  data  to  begin  in  April  1964  and  implementation  of  the  ADPS  by  July  1964  at  the 
Sacramento  Air  Materiel  Area,  utilizing  the  UNIVAC  1050/1  107  scheduled  for  implementation 
in  February  1964. 

In  the  system  implemented  in  July  1964,  the  Sacramento  Air  Materiel  Area  was  receiving 
intransit  data  cards  and  transportation  control  and  movement  documents  and  producing  five 
transit  reports.  In  May  1965  an  additional  requirement  to  provide  11  pipeline  reports  was 
imposed  by  Headquarters  AFLC  with  Headquarters  USAF  approval.  The  second  phase  consisted 
of  modifications  to  the  Shipment  Status  Report  from  the  Inventory  Management  Stock  Control 
and  Distribution  System  to  prepare  the  additional  reports.  This  modification  increased  the 
number  of  computer  runs  from  13  to  over  30.  Implementation  of  this  phase  was  accomplished 
on  schedule  in  July  1965. 

Due  to  the  size  of  the  development  activity  (six  people),  the  management  procedures 
were  quite  informal.  All  progress  reporting  between  the  programmers  and  the  project  leader 
were  informal.  The  project  leader  prepared  monthly  progress  reports  for  AFLC  showing 
percentage  of  completion  and  man-hours  expended.  The  development  and  implementation 
were  on  schedule. 

The  system  has  never  been  fully  documented.  All  documentation  at  Sacramento  is  still 
in  rough  draft  form.  The  project  leader  docs  most  of  the  documentation  with  contributions 
from  the  programmers.  AFLC  Manual  300-78  will  contain  the  system  documentation  when 
it  is  completed. 


SCHEDU  LF: 
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DESCRIPTION:  Field  units  submit  Transportation  Control  and  Movement  Documents  (TCMD) 
and  Intransit  Data  Cards  (IDC).  The  TCMD  serves  as  advance  notice  of  a  shipment  and  is  used 
primarily  for  suspense  and  control.  The  IDC  reflects  the  history  of  a  shipment.  The  submis¬ 
sions,  which  are  by  card,  paper  document,  and  AUTODIN,  are  stored  on  magnetic  tape  for  input 
to  the  computer.  On  a  daily  basis,  all  new  TCMD's  and  IDC's  go  through  a  complete  data  vali¬ 
dation.  Erroneous  data  are  recycled  to  their  source  for  correction,  and  valid  data  are  placed 
on  a  master  file.  Each  month,  (1)  all  TCMD  and  IDC  areas  are  summarized  by  activity,  and 
reports  are  sent  to  major  air  commands  and  field  activity  areas  to  police  MILSTAMP  pro¬ 
cedures;  (2)  IDC's  and  TCMD’s  held  in  suspense  are  compared  to  detect  delinquent  shipments; 
and  (3)  management  reports  are  produced. 


Transportation  Control 
and  Movement  Docu¬ 
ments  (TCMD)  and  In¬ 
transit  Data  Cards  (1CD) 
Received  From 
Field  Units 
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WORKLOAD: 


DATA  BASE 


Char.  In  I)aia  Baae:  28,680,000 

Pfrcfnt  oC  Char,  on  D/A  Storage-  NA 

Millisecond*  of  Acre**  Time  for  D/A:  NA 

No.  of  Data  Base  Record  t'ypea 

No.  of  Data  Base  Record*  19*1,880 

Pert  ••of  Growth  Rate  /Mo.  .  tlofc 

Char. /Mo.  of  Update  Input:  57, 88°. OOP 


PROCESSING 

FUNCTIONS 


Key  £  U  U.  5 


c 

a  c 


Char.  /Mo.  of  Input 

Volume: 

57.880.000 

No.  of  Input  Trana* 

action  Types: 

3 

No.  of  Input 

Data  Fielda: 

60 

Percent  of  Input 

Rejects: 

8 

1005. 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0% 


OUTPUTS 


Char  .  /Mo.  of  Out 
put  Volume: 

No  of  Output 
»  ormata: 

He«|Htnae  Time 
( set  onda). 


11,950.000 

21 

NA 


Peripheral 


Bate  Compute  r(«| 

( .umputi 

Total  Source  Inatrutltona 

24,310 

Unit 

Total  Objei  t  Instruction*: 
Hra.  /Mo.  of  Application 

97.250 

Unit 

Production. 

41 

27 

HARDWARE: 


Univac  1050 


Com  - 
pute  r 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

('liar. 

Mach. 

Add 

Time 

(us) 

Internal  Storage 

Extorr 

Mag  Tapes 

tal  Storage 

Dm 

Cycle 

lime 

(ns) 

Word/ 

Char. 

Sire 

(bits) 

Wo  rd  / 
Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapes 

T  rans. 
Rate 

No. 

Disks 

Trans. 

R  Mr 

UNIVAC 

1050 

9/63 

Char. 

117 

4  S 

6 

12K 

2- 

860-2 

8K  to 

1  33K 

None 

UNIVAC 

1107 

9/62 

Word 

4 

4 

36 

32,768 

16- 
850-2 
2-'  * 
851  -3 

8K  to 

1  33K 
25K~t"o* 
I20K 

1  - 

Fl  1-880 

360K 

Comment:  The  UNIVAC  1050  is  used  as  the  peripheral  computer  while  the  UNIVAC  1107 
does  the  main  system  processing. 


84 


MILSTAMP  Sheet  5  of  7 


SOFTWARE:  Software  delivered  with  the  equipment  by  UNIVAC  consisted  of  a  COBOL  compiler, 
an  assembler,  hardware  diagnostics,  debugging  aids,  an  Executive  Control  System  and  various 
utility  routines.  The  MILSTAMP  system  used  the  following  software  packages  on  the  UNIVAC 
1050:  (1)  card  to  tape;  (2)  tape  to  card;  (3)  tape  to  printer;  and  (4)  card  to  printer.  On  the 
UNIVAC  1107,  MILSTAMP  used  the  following  software:  (1)  a  sort  package;  (2)  a  merge  package; 
(3)  an  Executive  Control  System;  and  (4)  a  COBOL  compiler. 

Comment:  The  Executive  Control  System  provided  for  automatic  sequencing  of  a  scheduled 
set  of  computer  jobs,  allocation  of  memory  and  peripheral  equipment,  input /output  operations, 
and  concurrent  processing  of  1107  programs.  Difficulties  experienced  with  use  of  the  soft¬ 
ware  during  program  checkout  were  attributed  to  inadequate  documentation.  Discrepancies 
in  the  documentation  of  the  typewriter  messages  from  the  Executive  Control  System  presented 
a  particular  problem.  Three  UNIVAC  programmer  /analysts  were  extremely  useful  in  locating 
software  problem  areas. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  task  of  developing  the  system  at  SMAMA 
was  assigned  to  the  System  Section  oi  the  Centralized  Command  Systems  Branch  within  the 
Data  Services  Division.  Hq.  AFLC  supplied  the  system  specifications  from  which  came  the 
system  design  to  provide  the  required  reports.  The  analyst  responsible  for  the  system  de¬ 
sign  then  assigned  and  supervised  the  program  development  effort  through  to  final  implemen¬ 
tation.  Five  programmers  were  utilized  to  develop  the  system  and  write  the  programs  in 
COBOL.  Each  program  was  checked  out  separately,  using  dummy  test  input  from  the  analyst, 
with  no  formal  system  test.  A  24-hour  turn-around  was  normal  during  the  development  period, 
with  the  programmers  being  allowed  to  stand  by  during  their  tests  to  aid  the  operators  in  locat¬ 
ing  difficulties.  The  redesign  of  the  system  was  accomplished  to  produce  11  more  reports  and 
accept  additional  input.  Of  the  original  13  programs,  8  required  revision,  which  tended  to  re¬ 
duce  the  system  efficiency.  Difficulties  with  the  software  were  experienced  during  program 
checkout  and  this  was  attributed  to  inadequate  documentation.  Discrepancies  in  the  documen¬ 
tation  of  the  typewriter  output  messages  from  the  Executive  System  presented  a  particular 
problem.  The  programmers  relied  heavily  upon  3  programmer /analysts  supplied  by  UNIVAC 
to  locate  problem  areas  not  locatable  from  the  Executive  output.  The  original  system  checkout 
used  95  hours  on  the  1107,  and  114  hours  on  the  1050.  The  redesigned  system  checkout  re¬ 
quired  100  hours  on  the  1107,  and  200  hours  on  the  1050.  Due  to  the  size  of  the  development 
activity  (six  people),  the  management  procedures  were  quite  informal.  All  progress  report¬ 
ing  between  the  programmers  and  the  project  leader  was  informal.  The  project  leader  pre¬ 
pared  monthly  progress  reports  for  AFLC  showing  percentage  of  completion  and  man-hours 
expended.  These  reports  were  approved  by  the  Branch  Chief  to  whom  the  project  leader  made 
periodic  informal  progress  reports. 


FILE  CONVERSION:  The  TCMD  and  IDC  records  were  used  daily  as  input  for  creation  of 
MILSTAMP  tiles.  There  was  no  requirement,  therefore,  for  a  one-time  conversion  of 
any  records  or  files. 


85 


MILSTAMP  Sheet  6  of  7 


DOCUMENTATION:  System  documentation  has  not  progressed  beyond  a  draft  form.  It  is 
planned  that  formal  documentation  of  MILSTAMP  will  be  put  into  AFLC  Manual  300-78. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated 
to  System 

In  ADP 

In  Logistics 

Of  College 

Development 

Manager 

1 

1 

9 

4 

4 

Analyst 

1 

1 

9 

4 

U  nknown 

Prognmmei 

2 

5 

7 

1 .5 

U  nknown 

Operations 

Manager 

None 

Unknown 

Unknown 

Unknown 

Unknown 

Operator 

None 

4.5 

U  nknown 

Unknown 

OPERATIONS:  The  computer  operation  is  staffed  regularly  8  hours  a  day,  5  days  a  week,  plus 
any  additional  time  required  due  to  workload.  It  operates  as  a  closed  shop.  MILSTAMP  is  one 
of  several  applications  run  on  the  UNIVAC  1107/1050  computers.  A  daily  schedule  is  followed 
by  the  installation. 

Comment:  The  ‘'Other  Time"  in  the  pie  chart  is  manufacturer  modification  time. 


Prod  (Ml  I  .ST  AMP  app) 

29  hr. 

Prog  Dev  *  Mt  (MILSTAMP  app) 
4  hra  1 4 

Pr**d  (all  other  appa ) 

204  hra  2H< 


Prog  I**v  *  Mt  (all  other  appa) 
72  hra  10» 

t  h*  Loat  (all  other  appa) 

1  hra  1 1 

Set  lip 
14  hra  2* 


APPLICATION  PROGRAM  MAINT ENANCE :  Currently  there  are  two  programmers  (vacancies 
exist  for  two  more)  and  one  system  analyst  involved  in  program  maintenance.  Eacli  of  the 
programmers  spends  75  percent  of  his  time  on  MILSTAMP,  with  50  percent  for  the  analyst. 
Much  of  the  programming  maintenance  activity  is  developing  programs  and  procedures  for 
special  reports  required  by  Headquarters  USAF.  In  1965,  30  such  reports  were  produced. 
Program  corrections  and  improvements  take  up  the  remainder  of  the  time. 
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BENEFITS:  Proposed:  DOD  directed  all  DOD  agencies  to  implement  MILSTAMP  procedures. 
The  Air  Force  MILSTAMP  Central  Data  Collection  System  at  the  Sacramento  Air  Materiel  Area 
was  proposed  to  supply  data  on  all  AF  transportation  activities  to  the  Defense  Supply  Agency 
(DSA).  DSA  was  to  be  responsible  for  consolidating  transportation  information  from  all  DOD 
agencies.  Benefits  to  result  from  MILSTAMP  implementation  were  to  include  the  capability 
to  establish  standard  transit  and  hold  times,  permitting  an  evaluation  of  military  and  civilian 
carrier  performance.  Further  benefits  were  reduction  in  pipe-line  times,  resulting  in  reduc¬ 
tion  in  materiel  inventories. 

Actual:  MILSTAMP  potential  benefits  have  been  affected  by  lack  of  response  from  consignor'  or 
consignees  and  a  high  error  rate  from  those  who  have  responded.  Since  implementation,  re¬ 
sponse  has  continually  improved  and  the  error  rate  gradually  reduced  due  to  education  and  ag¬ 
gressive  policing  action. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev.) 


Proposed:  UnkCZ 

Actual:  61MBMHMHMH 

Comment:  The  DAP  prepared  Cor  MILSTAMP  did  not  state  the  man- 
months  that  would  be  required  for  Initial  development  of  the  system. 

It  did  state,  however,  that  two  analysts  and  three  programmers  would 
be  provided  for  Initial  program  development  from  existing  AFLC  re¬ 
sources.  A  major  redesign  of  MILSTAMP,  called  Phaje  II  develop¬ 
ment,  was  accomplished  In  the  period  May  to  July  1965.  Ten  actual 
man-months  of  development  effort  were  needed  for  Phase  II.  The 
actual  number  represents  both  Phase  I  and  Phase  Q  development  efforts. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  7 [  1 

Actual: 

Comment:  A  letter  from  Hq.  USAF  approving  the  AFLC  DAP  for 
MILSTAMP  stated  that  MILSTAMP  would  be  operational  not  later 
than  1  July  1964.  Many  problems  were  experienced  with  the  soft¬ 
ware  during  Initial  Phase  I  program  checkout  because  of  Inadequate 
documentation.  It  is  believed  that  this  factor  contributed  signifi¬ 
cantly  to  the  1 -month  schedule  slippage.  The  actual  number  shown 
here  reflects  the  8  months  elapsed  for  the  Initial  Phase  I  develop¬ 
ment  and  the  3-month  Phase  11  development. 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev. ) 
Proposed:  UnkCZ 

Actual:  70,847 

Comment:  Program  checkout  for  Phase  I  development  occurred  during 
the  period  17  March  to  31  July  1964.  Program  checkout  for  Phase  I 
required  95  hours  on  the  UNTVAC  1107  computer  and  114  hours  on  the 
UNIVAC  1050  computer.  Phase  11  program  checkout  was  accomplished 
In  the  period  May  to  July  1965,  when  2-1/2  hours  each  day  were  al¬ 
located  to  program  checkout.  Phase  11  program  checkout  required 
100  hours  on  the  UNIVAC  1107  and  200  hours  on  the  UNIVAC  1050. 

The  actual  cost  shown  here  Is  for  both  Phase  I  and  Phase  O. 


Hours /Month  of  Hardware  Use  for  Application  Production  (Op.) 

iProposed:  Unk  f~7 

Actual:  41 

Comment:  The  actual  number  reflects  usage  during  March  1966  on  the 
Uf'UV'Afi  1 107.  Twenty-nine  hours  were  used  for  MILSTAMP  application 
production  on  the  peripheral  UNTVAC  1050. 

Hours/Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 

Proposed:  Unk  CZ 

Actual:  6 

Comment:  The  actual  number  reflects  usage  during  March  1966  on  ths 
UNTVAC  1107.  Four  hours  were  used  for  MILSTAMP  program  mainte¬ 
nance  on  the  peripheral  UNIVAC  1050. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  4.5 

Comment:  The  DAP  for  MILSTAMP  stated  a  proposed  number  of  31  oper¬ 
ators  on  the  basis  of  a  normal  24-hour,  7-day  week  operation.  The  actual 
number  of  personnel  Is  prorated  from  24  operators  based  on  machine  hours 
for  MILSTAMP. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  2 

Comment:  The  actual  number  of  personnel  Is  prorated  from  2  programmers 
and  1  analyst  based  on  time  spent  on  MILSTAMP  program  maintenance. 

Dollars/Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  CZ 

Actual:  18,280  ■■■■■ 


Comment:  None. 


FUTURE  PLANS:  Currently,  there  are  no  plans  to  make  any  major  improvements  in  the 
programs  or  the  system.  There  is  a  requirement,  however,  that  MILSTEP  be  implemented 
1  October  1966.  There  is  also  some  discussion  that  DOD  would  like  SMAMA  to  become  the 
central  collection  agency  for  all  DOD  activities.  It  is  estimated  that  this  action  would  re¬ 
quire  13  new  processing  runs  and  modification  to  8  of  the  current  MILSTAMP  runs. 
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SYSTEM:  Missile  Simulation- -MISSIM  (IBM  7094) 


DATA  SYSTEM  DESIGNATOR:  B154  and  B276 


DATA  COLLECTION  DATE:  April  1966 


Contact  for  Additional  Information 

Data  Systems  and  Statistics 

Mathematical  Services  Laboratory 

Eglin  Air  Force  Base 

Valparaiso,  Florida 

Development 

Air  Proving  Ground  Center 

Eglin  Air  Force  Base 

Florida 

Maintenance 

Air  Proving  Ground  Center 

Eglin  Air  Force  Base 

Florida 

Pilot  Installation 

None 

First  Operational  Installation 

Air  Proving  Ground  Center 

Eglin  Air  Force  Base 

Florida 

Number  of  Operational  Installations 

1 

FUNCTION:  The  users  of  MISSIM  are  the  Deputy  for  Test  Operations  and  the  Deputy  for  Effec¬ 
tiveness  Test,  Air  Proving  Ground  Center  of  the  Air  Force  Systems  Command.  The  mission 
of  the  users  is  to  conduct  and  evaluate  Air  Force  weapons  effectiveness  tests.  MISSIM  functions 
as  a  research  and  development  support  system  to  simulate  the  firing  of  one  or  more  ground-to- 
air  missiles  at  an  aircraft  target  for  purposes  of  determining  the  closest  approach  of  the  mis¬ 
siles  to  the  target.  The  flight  path  of  the  target  is  described  with  data  from  a  control  radar 
tracking  an  actual  aircraft  flying  a  simulated  sortie. 


ORGANIZATION: 


(An&lyat  and  Immediate  Uaer)  (Analyst)  (Frogt  ammei  )  (Operator) 
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HISTORY:  Informal  discussion  at  the  Air  Proving  Ground  Center  (APGC)  between  the  user  (Dep¬ 
uty  for  Test  Operations)  and  the  developer /operator  (Mathematical  Services  Laboratory)  re¬ 
sulted  in  a  letter  dated  14  February  1963,  directing  the  Mathematical  Services  Laboratory  to 
produce  "a  missile  simulation  and  target  track  comparator  program''  for  the  IBM  7094.  The 
specifications  for  the  desired  programs  likewise  grew  from  informal  discussions  and  meetings. 

The  first  target  track  comparison  program  became  operational  in  August  1963  and  the 
first  missile  simulation  program  became  operational  in  September  1964.  Because  the  physical 
characteristics  of  the  guidance  radar  and  the  missile  be  ing*  simulated  have  changed  continually, 
the  Missile  Simulation  development  has  been  marked  by  continually  evolving  programs.  When 
the  program  changes  become  extensive  on  a  cumulative  basis,  the  Mathematical  Services  L?J  - 
oratory  rewrites  the  entire  program. 

Until  August  1965,  the  Missile  Simulation  suffered  from  a  relatively  low  priority  compared 
with  other  APGC  projects.  Since  that  time,  events  exterior  to  APGC  have  caused  the  simulation 
to  enjoy  a  high  priority. 

The  communication  flow  from  user  to  project  mathematician  to  programmer  was  rigidly 
adhered  to.  There  was  virtually  no  skipping  of  rungs  on  the  communication  ladder.  The  project 
mathematicians  acted  in  a  coordinator /analyst  role  between  the  user  and  programmer,  prin¬ 
cipally  for  the  more  technically  oriented  radar  and  missile  portions  of  the  simulation.  Communica¬ 
tion  between  the  user  and  analyst  was  infrequent,  whereas  communication  between  the  analyst 
and  programmer  occurred  daily.  There  was  no  comprehensive  system  design  document. 

The  Missile  Simulation  inputs  and  outputs  are  classified,  as  are  the  particular  technical 
characteristics  of  the  equipment  being  simulated.  The  initial  analysis  was  somewhat  hindered 
by  these  security  factors,  resulting  in  a  delay  in  development. 


SCHEDULE: 
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DESCR IPTION:  The  firing  of  one  or  more  ground-to-air  missiles  is  simulated  to  determine  the 
closest  approach  of  the  missiles  to  the  target.  Actual  target  track  data  are  gathered  at  APGC 
test  ranges  by  fl*;  ing  simulated  missions  with  actual  aircraft.  Two  radars  collect  data:  a  con¬ 
trol  radar  with  pre-established  accuracy  and  an  experimental  missile  guidance  radar. 


Real  Tima  Evanta 
al  APGC  P  ange  • 


N«>n-Raal  1  !<na  Evanta  al 
Mathamati*  al  Sarvltea  laboratory 


s' 

Simulation 

Pa  rimrlr  ra 
Control  f'arH* 

Simulati 
of  Mlaai 
1  argat 

i  1 (ring 
ila  at 

Raport 


T o  Pr ojact 
Mathamatlc  I  an 
(or  Validation 
of  Radar  Data 


Report 


to  Uaar  for 
Evaluation  of 
Mlaaila 
Effactlvanaaa 


1  o  Projact 
Mathamatlclan 
for  Validation  of 
Radar  Data 


•  r«il  a it«l  li.ii.l 

an.*  P.tr 

(••rtu  ‘.tatlat i«  al 

po 

Aiutlyaia 
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WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char.  /Mo.  of  Input 

Volume: 

77,540,000 

No.  of  Input  Trans¬ 

|2  (data): 

action  Types: 

15  (control)  I 

No.  of  Input 

115  (data); 

Data  Fields: 

|525  (control) 

Percent  of  Input 

Rejects: 

Unk 

-  s  c 

^  a  s 

Key  5W  US  <5 


!  L 

O  *  f 

o  «:o 


I  oof* 
90 
80 


Total  Source  Instructions:  21,180 

Total  Ohjei  t  Instructions:  84,000 

l(rs. /M<».  of  Application 
Production:  67 


Unk 

Unk 


Char.  / Mo.  of  Out¬ 

put  Volume: 

47,130.000 

No.  of  Output 

Formats: 

39 

Response  Time 

(seconds): 

NA 

HARDWARE: 


IBM  MO  1 
Number  1 


IBM  1401 
Number  2 


Com¬ 

puter 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal  Storage 

External 

Storage 

Peripheral  Devices 

Card  Reader /Punch 

Printer 

Cycle 

Time 

(us) 

Word/ 

Char. 

Size 

(bits) 

Word/ 

Char. 

Ca¬ 

pacity 

No. 

Read 

Speed 

(cards/ 

min) 

Punch 
Speed 
(cards / 
min) 

No. 

Speed 

(1pm) 

No. 

Mag 

Tapes 

Trans. 

Rate 

IBM 

7094-11 

4/64 

Word 

1.4 

1.4 

36 

32K 

21  - 

729  VI 

22.5K- 
62.  5K 

1- 

711 

250 

100 

1- 

716 

150 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

4K 

2- 

729 

22.5K- 
62. 5K 

1  - 
1402 

800 

250 

1  - 

1403 

600 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8K 

2- 

729 

22.5K- 

62.5K 

1  - 
1402 

800 

250 

2- 

1403 

600 

Comment:  Due  to  a  stauration  condition  on  the  large  computer  a  second  IBM  7094-11 
has  been  delivered  recently. 
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SOFT  WAR  E:  Software  for  the  IBM  7094  consisted  of  an  IBSYS  Executive  Monitor,  a  FORTRAN 
IV  compiler,  and  a  FAP  assembler.  The  software  was  delivered  by  IBM  with  the  equipment  in 
April  1966. 

Comment:  The  only  shortcoming  of  the  software  was  the  inability  of  IBSYS  to  handle  real-time 
inputs. 


APPLICATION  PROGRAM  DEVELOPMENT :  The  communications  between  user,  project  math- 
ematician,  analyst,  and  programmer  were  well  defined  by  management.  The  user  interfaced 
only  with  the  project  mathematician  or  analyst  who  in  turn  interfaced  with  the  programmer. 
Communication  between  user  and  analyst  was  infrequent  and  informal,  while  communication 
between  analyst  and  programmer  was  informal  with  little  documentation.  There  was  no  com¬ 
prehensive  system  design  document.  The  programming  effort,  conducted  at  the  Mathematical 
Services  Laboratory,  utilized  an  existing  IBM  7090  (later  7094)  computer  configuration.  Three 
concurrent  programming  activities  proceeded  during  development:  (1)  writing  new  programs  to 
reduce  the  raw  data  from  the  guidance  radar;  (2)  modification  of  existing  data  reduction  and 
comparative  programs  to  accept  a  new  type  guidance  radar  data;  and  (3)  programming  the  mis¬ 
sile  simulation  program  itself.  The  programs,  written  in  FORTRAN  IV  and  FAP  assembly  lan¬ 
guage,  were  checked  out  individually  and  not  as  a  system  due  to  their  extreme  independence. 
Checkout  of  the  simulation  program  was  hampered  by  lack  of  radar  data  tapes.  Records  of 
program  development  hours  were  not  kept.  The  programmers  documented  their  programs  when 
they  became  operational. 


FILE  CONVERSION:  No  file  conversion  was  involved  in  MISSIM  development. 
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DOCUMENTATION:  Design  documentation  was  limited;  communication  occurred  on  an  informal 
basis  between  analyst  and  programmer.  At  the  time  of  initial  operation,  the  programmer  created 
user  documentation  on  punched  cards,  which  could  be  updated  or  listed  easily.  There  was  no 
detailed  program  documentation. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Scientific 
Computation 

Of  College 

Development 

Manager 

1 

1 

1S.0 

1S.0 

4.0 

Analyst 

2 

2 

12.0 

11.0 

5.0 

Programmer 

3 

3 

6.0 

6.0 

4.0 

Operations 

Manager 

1 

0.3 

10.0 

9.0 

2.0 

Operator 

0 

2.1 

Unknown 

Unknown 

OPERATIONS: 
a  closed  shop. 


The  computer  operation  is  staffed  24  hours  a  day,  7  days  a  week.  It  operates  as 
MISSIM,  which  is  run  26  times  per  month,  is  one  of  many  applications  run  on  the 
IBM  7094/1401  (A  and  B)  computers.  IBSYS  controls  operations  on  the  IBM  7094  90  percent  of 
the  time,  doing  stacked  jobs.  Scheduling  is  on  a  "first  come,  first  served”  basis,  with  priority 
consideration.  A  50  to  150-hour  backlog  normally  exists. 

Comment:  Excellent  hardware  reliability  is  reflected  in  low  machine  maintenance  times.  It  was 
not  possible  to  determine  the  "other  time"  origin,  but  it  was  most  likely  "off  time." 


Off  M  hr*  S% 
Schd  Mt  2  hr*  1% 

M*ch  Error  Lost 
2  hr*  1% 

Idle  20  hr*  3% 
Set  Up  2Shr*  4% 

Chg  Lo*t  (all 
app*) 21  hr ■  )% 

Prog  D«v  ft  Mt 
(all  other  app*) 
38  hr*  3% 


Prod  (MISSIM 
*pp)  67  hr*  9% 


Prog  Dev  A  Mt 
(MISSIM  app) 

3  hr*  1% 

Prod  (all  other 
appa)  498  hr* 
68% 


Idle 

32  3  hr*  44% 


Prod  (MISSIM 
•  pp)  26  hr*  4% 

Prog  Dev  A  Mt 
1  hr  1%  (MISSIM  app) 


Prod  (all  other 
•  pp*)  202  hr*  28% 

Prog  Dev  A  Mt 

18  hr*  2%  (all  other  app*) 

Chg  Lost  (all 
■pp*)  3  hr*  1% 


IBM  1401  (A) 


Prod 

(MISSIM  app) 
37  hr*  5% 


Prod 

(all  other  app*) 
280  hr*  38% 


APPLICATION  PROGRAM  MAINTENANCE:  The  application  program  maintenance  effort  is  es¬ 
sentially  a  continuation  of  the  application  program  development  effort.  The  development  ana¬ 
lysts  and  programmers  are  also  the  maintenance  analysts  and  programmers  and  the  same  in¬ 
formal  methods  of  communication  among  user,  analyst,  and  programmer  are  used. 

Comment:  The  program  maintenance  effort  is  relatively  large  because  the  characteristics  of  the 
guidance  radar  and  missile  being  simulation  have  changed  continually.  Also,  the  users  continu¬ 
ally  impose  new  requirements  in  the  simulation  capability.  Programs  are  completely  rewritten 
when  accumulated  changes  become  extensive. 
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BENEFITS:  Proposed :  The  primary  benefit  from  MISSIM  was  planned  to  be  a  system  for  missile 
simulation  and  target  track  comparison. 

Actual:  A  system  of  programs  has  enabled  MISSIM  users  to  simulate  the  flight  of  one  or  more 
ground-to-air  missiles  at  an  aircraft  target  for  the  purpose  of  determining  the  closest  approach 
of  the  missile  to  the  target.  This  represents  a  capability  not  formerly  available  to  users  at 
APGC.  No  cost  saving  figures  are  available,  since  these  computations  were  not  made  prior  to 
MISSIM. 


COST  FACTORS: 


Man-Months  of  Drvflopmrnt  Effort  (Dyv.) 

Proposed:  Unk  CZ 

Actual:  66 

Comment:  No  formal  proposal  was  prepared  for  MISSIM.  The  project 
germinated  from  informal  discussions  between  PGO  (user)  and  PGM  (de¬ 
veloper).  These  discussions  resulted  In  a  letter  from  PGO  to  PGM  dated 
14  February  1963  requesting  that  "a  missile  simulation  and  target  track 
comparator  program*  be  developed  for  the  IBM  7094  computer.  Even 
though  the  user  did  not  rigidly  specify  the  system  characteristics  to  the 
developer,  continued  Informal  Interaction  resulted  in  a  system  that 
satisfies  the  current  user  needs. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  4  Q 

At  Inal:  )t  ■■■■■■HI 

Comment:  The  user,  PGO,  made  the  request  in  their  letter  to  the  de¬ 
veloper,  I’GM,  for  a  15  June  1963  initial  capability.  It  became  apparent 
that  this  date  was  unrealistic,  and  it  was  disregsrded.  The  actual  num¬ 
ber  ol  months  shown  here  Is  from  14  February  1963  to  the  current  date. 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 

Proposed:  Unk  CZ 

Actual:  Unk  V 

Comment:  Records  of  computer  hours  by  program  were  not  kept  before 
December  1964.  Some  programs  on  which  records  were  kept  after  that 
date  had  more  than  one  application.  Other  development  costs  not  included 
were  'or  checkout  runs  performed  to  assist  engineers  in  checkout  of  hard¬ 
ware  changes.  These  factors  make  it  impossible  to  determine  MISSIM 
program  checkout  hours. 

I fou r s /Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  Unk  CZ 

Actual:  67  ■■■■■■■■■■■ 

Comment:  The  actual  number  reflects  usage  during  March  1966  on  the 
IBM  70${.  Sixty-three  hours  were  used  for  MISSIM  application  production 
on  the  peripheral  IBM  1401  computer. 


Hours/Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 
Proposed:  Unk  □ 

)  HMMHi 

Comment:  The  actual  number  reflects  usage  during  March  19f<6  on  the  IBM 
7094.  One  hour  was  used  for  MISSIM  program  maintenance  on  the  periph¬ 
eral  IBM  1401  computer. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  1 

Commenl:  Tlie  actual  number  of  personnel  is  prorated  from  li.  people  on 
the  basis  of  machine  liuurs  for  MISSIM 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  .«! 

Comment ;  The  actual  number  of  per nonnel  Is  prorated  from  three  program¬ 
mers,  Iwo  analysis,  and  one  manager  onihe  basis  of  lime  devotrd  tnMlSSIM 
program  maintenance,  (  or  rent  programming  activity  la  considered  to  he 
more  closely  related  to  program  development  than  program  maintenance 
because  of  the  riuitinual'y  evolving  development  of  MISSIM  programs. 

Doll  ■>  r  s  /  Mouth  of  Hardware  Cost  (Op.) 

Proposed:  Unk  CZ’ 

Mi ■■■■ 

Comment ;  None 


FUTURE  PLANS:  MISSIM  undergoes  continual  modification  to  reflect  changes  in  the  guidance 
radar  inputs  and  mis sile  parameters.  Currently,  a  new  Rigid  Body  Program,  No.  827,  is  being 
checked  out  by  Lockheed,  Sunnyvale,  the  program’s  developers,  at  the  Mathematical  Services 
Laboratory.  This  program  is  functionally  equivalent  to  two  existing  programs,  nos.  595  and 
708,  in  that  it  accepts  both  real  and  theoretical  flight  data.  Program  827  al.so  includes  new  auto¬ 
pilot  equations  and  equations  of  motion.  The  majority  of  output  reports  from  program  827  are 
in  the  form  of  graphs  produced  on  the  Strombe rg- Carlson  4020  microfilm  recorder.  It  is  un¬ 
likely  that  program  827  will  completely  replace  595  and  708  since  it  requires  four  times  as  much 
computer  time  as  595  or  708.  Program  595  is  thus  being  modified  to  output  on  the  SC  4020  in  the 
same  manner  as  827.  Lockheed  also  is  developing  a  program,  no.  802,  to  produce  aircraft 
flight  data  which  will  be  input  to  827  in  the  theoretical  mode  of  operation. 
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SYSTEM:  Orbit  Determination  and  Analysis--ORBIT  (IBM  7044) 


DATA  SYSTEM  DESIGNATOR:  B01 1 


DATA  COLLECTION  DATE:  May  1966 


LOCATION:  * 


Contact  for  Additional  Information 

Data  Analysis  Branch 

Technical  Services  Division 

Air  Force  Cambridge  Research  Labs 
Hanscom  Field,  Bedford,  Massachusetts 

Development 

Air  Force  Cambridge  Research  Labs 
Laurence  G.  Hanscom  Field 

Massachusetts 

Maintenance 

Air  Force  Cambridge  Research  Labs 
Laurence  G.  Hanscom  Field 

Massachusetts 

Pilot  Installation 

None 

First  Operational  Installation 

Air  Force  Cambridge  Research  Labs 
Laurence  G.  Hanscom  Field 

Massachusetts 

Number  of  Operational  Installations 

1 

FUNCTION:  The  users  of  ORBIT  are  the  various  laboratories  (Aerospace  Instrumentation,  Data 
Sciences,  Meteorology,  and  other)  of  the  Air  Force  Cambridge  Research  Laboratories.  The 
mission  of  the  users  is  to  conduct  basic  and  applied  research  in  the  environmental  sciences  and 
in  certain  areas  of  the  physical  sciences.  ORBIT  functions  as  a  research  and  development  sup¬ 
port  system  to  accurately  determine  earth  satellite  orbits  by  the  minimum  variance  method. 


ORGANIZATION: 


(D*v«lop«r) 
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HISTORY:  The  various  laboratories  at  the  Air  Force  Cambridge  Research  Laboratories 
(AFCRL)  have  the  authority  to  contract  out  individually  for  support  in  their  missions  if  no  capa¬ 
bility  exists  in-house.  Several  requests  for  support  prompted  the  Data  Analysis  Branch  of  the 
Technical  Services  Division  to  ask  approval  to  develop  a  general  orbit  determination  and  analysis 
system.  By  creating  this  capability  within  the  Technical  Services  Division,  duplication  of  effort 
would  be  avoided.  Approval  from  the  Technical  Services  Division  was  granted  in  January  1964. 

A  1-year  contract  was  let  to  the  Martin  Company  in  May  1964  to  develop  the  mathematical  ap¬ 
proach  and  to  verify  it  with  an  operational  set  of  computer  programs.  At  the  end  of  this  initial 
contract  period,  the  report  on  the  mathematical  method  was  published  and  the  contract  was 
renewed.  The  computer  programs  were  improved  and  the  rest  of  the  documentation  produced. 
May  1966  is  considered  the  operational  date,  but  a  usable  system  of  limited  capability  existed  in 
early  1965. 

The  contract  was  monitored  by  a  member  of  the  Data  Analysis  Branch.  This  contract  re¬ 
quired  very  little  supervision  since  it  was  estimated  that  only  5  percent  of  the  monitor's  time  was 
actively  taken  with  this  responsibility.  Since  the  analysis,  programming,  and  checkout  were 
performed  on-site,  daily  communication  was  possible  between  the  contractor  and  AFCRL  on  an 
informal  basis.  On  an  official  basis,  the  contractor  was  required  to  submit  quarterly  progress 
reports. 

Complete  maintenance  and  user  documentation  were  published  in  May  1966. 


a 

/ 


S CHE DU  LE: 
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DESCRIPTION:  This  system  performs  the  accurate  determination  of  earth  satellite  orbits  by  the 
minimum  variance  method.  Input  consists  of  lead  control  cards  followed  by  observation  cards 
(usually  from  SPADATS).  After  the  lead  cards  are  interpreted,  the  observation  cards  are  loaded 
onto  the  disk  to  be  read  when  needed  during  the  main  processing.  A  print  tape  is  produced  con¬ 
taining  ephemeris  data  as  well  as  a  binary  history  tape  which  is  used  for  further  analysis  by 
other  programs. 


Normally 

From 

SPADATS 


AFCRL 
Project 
Personnel 
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WORKLOAD: 


PROCESSING 

FUNCTIONS 


HARDWARE: 


IBM  7044  IBM  1460 


Com¬ 

puter 

Flret 

Dellv- 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(u») 

Internal  Storage 

External  Device. 

Peripheral  Device. 

Card  Reader /Punch 

Printer 

PT  Reader /Punch 

Mag  Tape. 

Dlak 

Cycle 

Time 

(u») 

Word/ 

Char. 

SUe 

(bit.) 

Word/ 

Char. 

Ca¬ 

pacity 

No. 

Mag 

Tape. 

Tran., 

Rate 

No. 

Disk. 

Trane. 

Rate 

(char./ 

aec) 

Char. 

Ca¬ 

pacity 

Ac¬ 

cess 

Time 

(m.) 

No. 

Read 

Speed 

(card./ 

min) 

Punch 

Speed 

(card. 

/min) 

No. 

Speed 

(1pm) 

No. 

Read 

Speed 

[char./ 

min) 

Punch 
Speed 
(char.  / 
min) 

IBM 

7044 

7/63 

Word 

5 

2.5 

36 

32K 

5- 

729  V 

to 

60K 

1301-1 

90.100 

27,960, 

000 

180 

None 

... 

... 

None 

... 

None 

... 

IBM 

1460 

10/63 

Char. 

108 

6 

6 

8K 

1- 

729  V 

to 

60K 

None 

— 

1402-3 

800 

250 

' 

1- 

1403-3 

1,100 

1012 

500 

150 

Comment:  The  ORBIT  system  was  initially  developed  for  an  IBM  7090  system.  Time 
on  the  IBM  7090  was  rented  from  a  service  bureau. 
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SOFTWARE:  Software  for  the  IBM  7044  supplied  by  IBM  included  an  IBSYS  executive  system 
which  has  FORTRAN  IV  and  COBOL  compilers,  and  MAP  and  BAP  (a  subset  of  MAP)  assem¬ 
blers.  Software  packages  also  used  are  the  SHARE  program  library  packages,  the  IBM- 
distributed  program  library,  a  FORTRAN  IV  computer  system  library,  and  the  IBM  scientific 
subroutine  package  for  System  360  which  was  converted  to  the  IBM  7  044. 

Comment:  Since  the  application  programs  were  originally  written  partially  in  FAP  for  the  IBM 
7  094,  they  had  to  be  converted  to  run  in  MAP  on  IBSYS.  Two  people  are  involved  in  maintenance 
of  the  software. 


APPLICATION  PROGRAM  DEVELOPMENT:  Analysts  from  the  Martin  Company  produced  func¬ 
tional  flow  charts  at  the  subroutine  level  and  described  the  sequence  of  computation.  The  de¬ 
tailed  programming  problems  were  left  to  the  programmers.  The  initial  set  of  operational 
programs  was  written  in  FORTRAN  II  for  an  IBM  7090  by  Martin  Company  programmers  at 
AFCRL.  They  were  subsequently  redesigned  for  an  IBM  7044  configuration  which  required  the 
following:  (1)  segmentation  of  programs  due  to  the  large  size  of  the  IBSYS  monitor;  (2)  redesign 
to  take  advantage  of  the  disk  on  the  7044  configuration;  and  (3)  coding  changes  caused  by  certain 
inconsistencies  between  the  7090  FORTRAN  II  and  7044  FORTRAN  IV  languages..  Since  the  anal¬ 
ysis,  programming  and  checkout  were  performed  on  site,  daily  communication  was  possible 
between  contractor  and  AFCRL,  represented  by  the  Data  Analysis  Branch,  on  an  informal  basis. 
The  contractor  was  required  to  submit  quarterly  progress  reports.  Thirty-one  programs  make 
up  the  ORBIT  system.  Ten  are  written  in  FAP,  the  rest  in  FORTRAN  IV.  Sixty-seven  hours  of 
computer  time  were  required  for  program  checkout.  Thirty-three  of  these  hour 4  were  on  the 
IBM  7044  and  34  hours  were  on  the  IBM  7090.  Three  checkout  runs  per  day  on  the  7044  to  one 
per  day  on  the  7090  were  possible,  with  the  programmers  allowed  to  observe  their  runs  if 
desired. 


FILE  CONVERSION:  No  file  conversion  was  involved  in  ORBIT  development. 
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DOC  U  M  E  N  T  ATI  ON :  "Orbit  Determination  and  Analysis  by  the  Minimum  Variance  Method" 
(AFCRL  65-579),  a  document  describing  the  technical  approach  taken  in  the  development  of  the 
system,  was  published  in  August  1965.  Informal  user  documentation  and  program  listings  were 
available  in  early  May  1 966*  followed  by  complete  maintenance  and  user  documentation  later 
that  month. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

in  Scientific 
Computation 

Of  College 

Development 

Managor 

1 

1 

8.0 

8.0 

4.0 

Analyst 

1 

1 

8.0 

8.0 

7.0 

Programmer 

2 

2 

4.0 

4.0 

5.0 

Operations 

Managor 

6 

0.0 

11.0 

11.0 

4.0 

Operator 

12 

0.1 

6.0 

6.0 

OPERATIONS:  The  computer  operation  is  staffed  as  required.  Current  workload  normally  re- 
quires  staff  24  hours  a  day,  7  days  a  week.  It  operates  as  a  closed  shop.  ORBIT  is  one  of  many 
applications  run  on  the  IBM  7044/1460  computers.  All  jobs  are  run  under  the  IBSYS  monitor. 
ORBIT  runs  an  average  of  six  times  a  month.  Only  express  runs,  up  to  5  minutes  and  50  pages 
of  printed  output,  are  run  during  normal  working  hours. 

Comment:  Excellent  computer  reliability  is  reflected  in  the  low  machine  maintenance  times. 


Off 

60  hi 

Sch 
10  hi 

Mach  Error 
1  1 


42  ti 

Chg  Loat  (all 

7  hri 

pTogDov*  Mt(all  othar  aj 

1  hi  .  r 

Off 

64  hra  <*. 

Schd  Mt 
12  hra  2% 

Mach  Error  Loat 
I  hr  I* 

Unachd  Mt 
2  hra  1% 

Idle 

343  hra  43% 

IBM  1460 


APPLICATION  PROGRAM  MAINTENANCE:  The  ORBIT  system  does  not  require  much  mainte¬ 
nance.  A  new  atmospheric  model  is  inserted  each  year  and  modification  in  support  of  particular 
satellite  programs  is  very  infrequent.  Maintenance  is  done  by  the  developers,  the  Martin 
Company. 

Comment:  The  small  requirement  for  program  maintenance  arises  from  the  fact  that  the  system 
has  been  operational  for  a  relatively  long  period  of  time. 
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BENEFITS:  Proposed:  The  primary  benefit  from  ORBIT  was  planned  to  be  an  orbit  determination 
and  analysis  capability,  which  had  not  existed  in  the  past.  This  capability  was  to  be  available  to 
any  division  within  AFCRL,  and  therefore  had  to  be  general  in  nature.  The  basic  analytic  tech¬ 
nique  to  be  used  in  the  orbit  determination  was  the  method  of  minimum  variance. 

Actual:  ORBIT  provides  the  orbit  determination  and  analysis  capability  that  was  required.  It 
may  be  assumed  that  a  considerable  saving  in  elapsed  time  and  personnel  costs  (over  manual  pro¬ 
cedures)  was  realized  with  the  implementation  of  ORBIT. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev.) 

Proposed:  UnkCZ 

Corwnent:  An  RFP  was  sent  oat  tn  January  1964  with  approval  by  the 
Technical  Services  Division  at  AFCRL.  A  "cost-plus"  contract  was 
awarded  in  May  1964  to  Martin  Co.  for  work  to  start  1  June  1964.  There 
were  no  detailed  task  statements  tn  the  contract.  The  actual  number  of 
man-months  shown  here  reflects  what  has  been  expended  to  date. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  Unk  CZ 


Comment:  The  initial  contract  awarded  to  Martin  Co.  was  for  1  year. 
The  contract  was  renewed  for  another  year  and  is  currently  scheduled 
to  end  1  June  1966.  The  actual  number  of  months  shown  here  reflects 
both  contracts. 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 


Proposed:  Unk  CZ 

Actual:  1 8.0S0  ■■■■Hi 

Comment:  Program  checkout  has  required  to  date  34  hours  on  the  IBM 
7090  and  33  hours  on  the  IBM  7044.  The  actual  cost  shown  here  Is  for  the 
hours  used  on  both  the  IBM  7044  and  the  IBM  7090. 

Comment:  None . 

Hour. /Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  Unk  CZ 

I 

Comment:  Reflects  usage  during  March  1966  on  the  IBM  7044  com* 
puter.  The  IBM  1460  was  not  used  for  ORBIT. 


FUTURE  PLANS:  The  Computer  Processing  Branch  at  AFCRL  hopes  to  augment  the  present 
computer  system  to  an  IBM  7094/7044  coupled  system  to  alleviate  the  overloaded  condition  now 
in  existence.  This  will  not  affect  the  ORBIT  system.  There  are  no  design  changes  contemplated 
for  ORBIT  system  programs. 


Houra/Month  of  Hardwara  Uss  for  Program  Maintenance  (Op,) 

Proposed:  UnkCZ 

Actual:  0 1 

Comment:  Reflects  usage  during  March  1966  on  the  IBM  7044  computer. 
The  IBM  1460  was  not  used  for  ORBIT. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  UnkCZ 

Actual:  0. 1 

Comment:  The  actual  number  of  personnel  is  prorated  from  12  operators 
and  6  managers  on  the  basis  of  machine  hours  for  ORBIT. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  UnkCZ 

Actual:  01 

Comment:  None. 

Dollars/Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  CZ 
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SYSTEM:  Priority  Distribution  System--PDS  (RCA  301) 


DATA  SYSTEM  DESIGNATOR:  D032A 


DATA  COLLECTION  DATE:  April  1966 


Contact  for  Additional  Information 

Comptroller  (Data  Management  Division) 
Headquarters,  Air  Force  Logistics  Cmd. 
Wright-Patterson  Air  Force  Base 

Dayton,  Ohio 

Development 

Headquarters,  Air  Force  Logistics  Cmd. 
Wright-Patterson  Air  Force  Base 

Ohio 

Maintenance 

Headquarters,  Air  Force  Logistics  Cmd. 
Wright-Patterson  Air  Force  Base 

Ohio 

Pilot  Installation 

None 

First  Operational  Installation 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Number  of  Operational  Installations 

7 

FUNCTION:  The  users  of  PDS  are  seven  AFLC  Air  Materiel  Areas--SAAMA,  SMAMA, 
OCAMA,  MAAMA,  OOAMA,  WRAMA,  and  MOAMA,  The  mission  of  the  users  is  logistic  and 
system  support  management  for  specific  weapon  systems.  PDS  is  a  subsystem  of  the  Inventory 
Management  Stock  Control  and  Distribution  System  and  functions  as  a  management  support  sys¬ 
tem  to  provide  for  the  expeditious  processing  of  high-priority  requisitions  and  associated  trans¬ 
actions  received  from  Air  Force  bases,  AFLC  AMA's  and  contractors,  Defense.  Supply  Agency, 
Military  Assistance  Program,  and  other  DOD  and  U.  S.  Government  agencies. 


ORGANIZATION: 


(On-*ite  Sy item  Malnt«n*nc«)  (Operator) 
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HISTORY:  In  I960  the  Air  Force  Logistics  Command  (AFLC)  established  the  Inventory  Manage¬ 
ment  Stock  Control  and  Distribution  (IMSC&D)  System  for  the  stock  control  and  distribution  func¬ 
tion  at  all  AFLC  depots  on  the  IBM  7080.  This  system  gave  a  12-  to  24-hour  response  to  the 
customer's  request,  with  emergencies  handled  manually.  Changes  in  operational  concepts  and 
requirements,  however,  increased  the  demand  for  faster  response.  AHeadquarters,  USAF,  task 
group  recommended  that  AFLC  formulate  plans  to  implement  a  standard  depot  inventory  manage¬ 
ment  package  with  random  access  and  rapid  response  for  supply  distribution  data  handling. 

AFLC  proposed  to  acquire  a  small-scale  random  access  computer  to  be  used  in  conjunction  with 
the  IBM  7080  to  process  priority  transactions  as  received,  but  later  decided  a  separate  priority 
processing  system  should  be  developed  which  would  operate  in  conjunction  with  the  present 
IMSC&D.  The  development  of  this  system  (PDS)  could  satisfy  the  desired  processing  time  cri¬ 
teria  with  a  minimum  of  cost.  This  concept  was  accepted  by  Headquarters  USAF  and  approval 
was  given  for  development  and  implementation  of  the  system. 

Program  development  of  PDS  took  place  at  Headquarters,  AFLC  and  was  distributed  as  a 
package  to  the  Air  Materiel  Areas  using  the  system.  Within  the  AFLC  Data  Center,  adata  systems 
project  office  directed  the  analysts  and  programmers  in  the  PDS  development.  This  office  de¬ 
veloped  the  detailed  system  design  under  the  specifications  set  forth  by  the  Data  Management 
Division,  AFLC.  While  the  detailed  system  was  being  designed  and  approved  by  the  Data  Man¬ 
agement  Division,  training  was  being  conducted  at  Headquarters  AFLC  for  analysts,  program¬ 
mers,  and  operators.  During  the  development  phase,  relatively  minor  changes  were  required 
in  the  system  design  for  MILSTAMP  requirements.  The  PDS  is  currently  undergoing  system 
design  modifications  and  a  complete  reprogramming  effort  in  order  to  incorporate  new  process¬ 
ing  requirements  imposed  by  Department  of  Defense  MILSTRAP  procedures. 

The  documentation  for  the  PDS  is  contained  in  one  manual,  AFM  300-20.  There  are  no  sep¬ 
arate  operator's,  user's,  or  programmer's  manual.  The  program  maintenance  function  is  car¬ 
ried  on  at  the  AFLC  Data  Center  and  any  program  changes  or  modifications  require  changes  in 
AFM  300-20. 

PDS  is  operational  at  the  following  seven  sites:  San  Antonio  AMA,  Sacramento  AMA, 
Oklahoma  City  AMA,  Ogden  AMA,  Warner  Robbins  AMA,  Mobile  AMA,  and  Middletown  AMA. 


SCHEDULE: 
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DESCRIPTION:  Each  day  the  PDS  loads,  via  punched  cards  and  magnetic  tape,  the  Data  Disk 
File  with  the  tables  and  records  necessary  to  process  high-priority  supply  transactions.  Supply 
transactions  are  edited  to  validate  elements  of  data.  Those  transactions  which  are  valid  are 
core  memory  transmitted  to  the  other  processor,  where  documents  are  prepared  for  output.  At 
the  completion  of  the  daily  run,  the  data  records  are  retained  on  magnetic  tape  for  the  next  cycle 
of  the  system. 
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WORKLOAD: 


DATA  BASE 

Char.  In  Data  Baee: 

116.400.000 

Percent  of  Char,  on  D/A  Storage: 

100 

Millisecond*  of  Accee*  Time  for  D/As 

79 

No.  of  Data  Bate  Record  Type*: 

• 

No.  of  Data  Base  Record*: 

169.300 

Percent  Growth  Rate  /Mo. : 

Unit 

Char.  / Mo.  of  Update  Input: 

4.390.000 

INPUTS 


Char  / Mo.  of  Input 
Volume: 

No.  of  Input  Trane* 
action  Types: 

No.  of  Input 
Data  Tlelde: 
Percent  of  Input 
Rejects: 


Char.  / Mo.  of  Out¬ 

put  Volume: 

9,590.000 

No.  of  Output 

Format*: 

20 

Response  Time 

(seconds): 

NA 

HARDWARE: 
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SOFTWARE:  The  only  software  for  the  RCA  301 's  supplied  and  required  is  the  symbolic  assem- 
bly  language  assembler  which  was  developed  specifically  for  this  system  due  to  the  unusual 
hardware  configuration. 

Comment:  Although  other  software  is  available  for  the  standard  RCA  301  configuration,  this 
software  will  not  operate  on  the  dual  processor  PDS  configuration.  Sufficient  need  did  not  exist 
for  this  software  to  warrant  conversion  for  the  PDS  configuration.  A  number  of  errors  were  de¬ 
tected  in  the  assembler  while  checking  out  PDS  application  programs.  These  errors  occurred 
primarily  because  the  assembler  was  written  concurrently  with  application  program  development. 


APPLICATION  PROGRAM  DEVELOPMENT:  A  data  systems  project  office  was  established 
within  Hq.  AFLCData  Center  to  direct  programmers  and  analysts  on  the  development  of  PDS. 

A  detailed  systems  design  was  developed  by  this  office  and  approved  by  the  Data  Management 
Division  of  AFLC,  which  had  supplied  the  specifications.  The  programmers  had  continual  access 
to  the  RCA  301  for  the  checkout  of  PDS.  Many  of  the  problems  encountered  during  the  develop¬ 
ment  phase  can  be  attributed  to  the  fact  that  the  programmers  and  RCA  personnel,  including  2 
programmers,  were  inexperienced  in  the  dual  processor  computer  configuration.  Program 
documentation  was  a  joint  effort  of  analysts  and  the  responsible  programmer.  The  21  programs 
were  written  in  RCA  symbolic  assembly  language.  Monthly  progress  reports  on  percentage  of 
completion  and  man-hours  expended  were  prepared  by  the  project  office  and  submitted  to  Hq. 
AFLC.  The  dual  processor  configuration  necessitated  the  creation  of  an  unusual  programming 
technique  to  allow  one  processor  to  verify  transactions  while  the  other  processor  is  formatting 
and  producing  the  output  products.  System  design  changes  during  development,  such  as  addi¬ 
tional  transaction  types,  did  not  significantly  affect  the  implementation  schedule. 


FILE  CONVERSION:  The  IMSC  and  D  records  are  used  daily  as  input  for  creation  of  the  priority 
distribution  system  records.  There  was  no  requirement,  therefore,  for  a  one-time  conversion 
of  any  records  or  files. 
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DOCUMENTATION:  All  system  documentation  is  contained  in  Air  Force  Manual  AFM300-20. 
There  are  no  separate  operator,  user,  and  programming  manuals. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Logistics 

Of  College 

Development 

Manager 

3 

3 

8.0 

6.5 

2.0 

Analyst 

6 

6 

5.5 

5.0 

Unknown 

Programmer 

9 

9 

7.0 

1.5 

Unknown 

Operations 

Manager 

None 

Unknown 

Unknown 

Unknown 

Unknown 

Operator 

6 

10 

Unknown 

Unknown 

OPERATIONS:  The  computer  operation  at  SMAMA  is  scheduled  for  processing  and  report  gen¬ 
eration  18  hours  per  day,  7  days  per  week.  Three  hours  each  per  day  are  allotted  to  loading/ 
unloading  of  PDS  and  to  preventive  maintenance.  A  daily  schedule  is  utilized  by  SMAMA. 


APPLICATION  PROGRAM  MAINTENANCE:  There  are  currently  seven  programmers  involved  in 
full-time  program  maintenance  at  Headquarters  AFLC  and  two  programmers  at  SMAMA  devoting 
7  5  percent  of  their  time  to  PDS.  Information  concerning  the  number  of  maintenance  program¬ 
mers  at  the  other  AMA'swasnot  available.  Because  of  disk  problems,  some  of  the  programs 
are  being  rewritten  to  provide  automatic  restart/ recovery  procedures  with  more  elaborate  disk- 
read  checks  and  edits.  A  second  current  program  maintenance  activity  is  reprogramming  to 
include  back  orders  on  the  PDS  master  file.  Headquarters  AFLC  and  SMAMA,  together,  have 
six  system  analysts  working  on  PDS  program  maintenance.  They  are  currently  involved  in  sys¬ 
tem  design  modifications  to  incorporate  new  processing  requirements  imposed  by  DOD 
MILSTRAP  procedures. 

Comment:  None. 
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BENEFITS:  Proposed:  PDS  was  proposed  to  handle  the  high-priority  requests  that  could  not  be 
handled  by  the  Inventory  Management  Stock  Control  and  Distribution  System.  By  1963,  approxi¬ 
mately  40  percent  of  the  total  requests  submitted  required  rapid  response. 

Actual:  Through  the  use  of  direct  access  storage  devices,  PDS  was  able  to  provide  the  required 
response  time  at  a  minimum  cost. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev.) 

Proposed: 

Unk  CZ 

Actual: 

Comment:  No 
in  rcaponae  to 
mutated  detail 

formal  DAP  was  prepared  for  PDS.  The  system  developed 
the  recommendation  of  a  Hq.  USAF  task  group  which  for- 
plans  and  programs  for  the  implementation  of  PDS. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed: 

161 _ 1 

Actual: 

Comment:  The  schedule  slippage  was  due  to  »  delay  in  equipment  selec- 
tion  and  the  fact  that  neither  the  Air  Force  personnel  nor  the  RCA  per- 
tonnel  had  previous  experience  on  the  RCA  301  dual  processor 
configuration. 

Dollars  ot  Hardware  Cost  lor  Program  Checkout  (Dev.) 
Proposed:  UnkQ 

Actual:  151,780  HHIHBHHi 

Comment:  Program  and  system  checkout  of  PDS  required  1,884  hours 
on  the  RCA  301  configuration. 

llours/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  UnkCZ 

Actual: 

Comment:  The  actual  number  reflects  the  total  hours  used  during 
Marc  h  1<H6  for  PDS  application  production  on  both  RCA  301  processors 
at  SMAMA. 


Hours/Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 

Proposed:  Unk  l~7 

■■■■■■■■■■I 

Comment:  The  actual  number  reflects  the  total  hours  used  for  PDS  pro- 
gram  maintenance  during  March  1966  on  both  RCA  301  processors  at 
SMAMA.  All  PDS  program  maintenance  is  done  at  Hq.  AFLC.  The  opera' 
tional  site  programmers  only  collect  program  error  data  to  send  to  Hq. 
AFLC  and  install  corrections  from  Hq.  AFLC. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  1 1  1  I 

Actual:  10  ■■■■■ 

Comme nt •  The  actual  number  of  personnel  represents  operators  at 
SMAMA .  The  PDS  system  is  not  operational  at  Hq.  AFLC. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  ■■■■■■■■■■■■ 

Comment:  The  actual  number  of  personnel  is  prorated  from  two 
programmer  a  at  SMAMA  on  the  basis  of  tirhe  spent  on  PDS  program 
maintenance  and  seven  programmers  at  Hq.  AFLC  who  devote  full 
time  to  PDS  program  maintenance. 

Dollars/Month  of  Hardware  Cost  (Op.) 

Proposed:  17.<H>0l  1 

Actual:  17,3' 

Comment:  None. 


FUTURE  PLANS:  This  system  is  currently  undergoing  system  design  modifications  and  a  com¬ 
plete  reprogramming  effort  in  order  to  incorporate  new  processing  requirements  imposed  by 
DOD  MILSTRAP  procedures,  to  be  implemented  1  July  1966.  Further  into  the  future,  changes 
are  anticipated  to  meet  several  new  DOD  MIL  systems  such  as  MILSTEP  and  MILSTAAD. 

The  effects  of  these  changes  should  be  considerable  although  they  cannot  be  fully  determined 
at  this  time. 
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SYSTEM:  Major  Air  Command  Personnel  Data  System-Officers  65--PDSO/MAC  (H800/H200) 


DATA  SYSTEM  DESIGNATOR:  E101A,  E053,  E517 
DATA  COLLECTION  DATE:  April  1966 


Contact  for  Additional  Information 

Headquarters,  Air  Training  Command 
Randolph  Air  Force  Base 

San  Antonio,  Texas 

Development 

Headquarters,  Air  Training  Command 
Randolph  Air  Force  Base 

Texas 

Maintenance 

Headquarters,  Air  Training  Command 
Randolph  Air  Force  Base 

Texas 

Pilot  Installation 

None 

First  Operational  Installation 

Headquarters,  Air  Training  Command 
Randolph  Air  Force  Base 

Texas 

Number  of  Operational  Installations 

8 

FUNCTION:  The  users  of  PDSO/MAC  are  the  Management  Information  Offices  of  the  major  air 
commands  and  the  Consolidated  Base  Pe rsonnel  Offices  of  the  various  Air  Force  bases.  The 
mission  of  the  users  is  maintenance  of  personnel  data,  assignments,  promotions,  accessions, 
strengths,  and  planning.  PDSO/MAC  functions  as  a  management  support  system  to  create,  edit, 
control,  retrieve,  distribute  and  display  active  duty  officer  personnel  data.  The  system  inte¬ 
grates  personnel  information  from  the  base  to  the  major  command  level  and  then  to  USAF  head¬ 
quarters  level. 


ORGANIZATION: 


(U»er) 
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HISTORY :  MAC  PDS-O  65  evolved  from  PDS-O  63.  No  formal  DAP  was  prepared  for  MAC 
PDS-O  65,  but  its  development  was  recognized  and  authorized  as  part  of  the  overall  vertically 
integrated  personnel  data  system  to  be  developed  by  the  Military  Personnel  Center  (MPC). 

MAC  PDS-O  63  programs  in  COBOL  for  the  Honeywell  800/200  computers  were  developed  by 
the  Air  Training  Command  (ATC)  at  Randolph  AFB  for  the  Inquiry  System  and  by  HEDCOM  at 
Bolling  AFB  for  the  Maintenance  System.  For  MAC  PDS-O  65,  MPC  integrated  the  Major  Air 
Command  (MAC)  data  base  with  the  MPC  and  Consolidated  Base  Personnel  Office  (CBPO)  data 
bases  and  completely  rewrote  the  Maintenance  System.  For  the  Inquiry  System,  MPC  adapted 
and  modified  in  varying  degrees  the  PDS-O  63  programs.  Some  of  the  inquiry  programs  proved 
to  be  rather  inefficient  in  COBOL  and  were  reprogrammed  by  Honeywell  in  assembly  langua^*. 

MAC  PDS-O  65  was  developed  and  is  maintained  by  MPC  and  distributed  to  the  MAC’S  for 
implementation.  Since  the  MAC  computers  (Honeywell  800/200  system)  may  differ  from  one 
another  in  configuration,  the  personnel  at  each  MAC  retrofit  the  basic  MAC  PDS-O  65  to  their 
own  computer.  Furthermore,  the  MAC'S  may  develop  command-unique  "add-ons"  to  their 
PDS-O  system.  All  maintenance  and  changes  in  the  basic  system  must  be  done  by  MPC. 

Two  teams  were  formed  at  MPC.  One  developed  the  maintenance  programs  and  the  other 
developed  the  inquiry  programs.  Several  of  the  inquiry  programs  were  adaptations  and  modifica¬ 
tions  of  PDS-O  63  programs.  The  personnel  assigned  were  experienced  programmers  and  per¬ 
formed  both  the  systems  analysis  and  programming  function.  The  computer  is  in  a  secured  area, 
but  this  has  not  been  detrimental  to  implementation  or  operation. 

Standard  Air  Force  documentation  and  program  reporting  procedures  were  employed 
during  development  as  specified  in  AFM  171-10.  The  manual,  AFM  30-3,  specifying  user  pro¬ 
cedures,  was  produced  partially  by  the  development  effort. 

MAC  PDS-O  65  is  operational  at  the  following  eight  MAC  Hqs.  :  SAC,  TAC,  ADC  ATC 
PACAF,  USAFSS,  USAFE,  and  HEDCOM. 


SCHEDULE: 
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DESCRIPTION:  The  system  consists  of  a  series  of  computer  programs  that  create  a  merged 
manpower -personnel  data  file,  which  in  turn  is  used  as  input  to  a  library  of  computer  sort  ap¬ 
plications  for  production  of  recurring  reports.  The  sort  programs  have  the  ability  to  be  altered 
on  a  one-time  basis  in  order  to  provide  inquiry  of  a  selected  portion  of  any  or  all  of  the  recur¬ 
ring  reports  on  an  as-required  basis. 


t  rwn  Wait 
•I  MAC 


FU.  M.N.UMI  Suhiyitim 


USA*  MAC 

via 

AUTODIN 


In  CBPO'a 
AUTODIN 


I"  Manaf.manl 

Inlormatinn 

OKU# 
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SOFTWARE:  Software  for  the  H800  consisted  of  a  COBOL  61  compiler  and  an  ARGUS  assem¬ 
bler.  The  software  was  delivered  by  Honeywell  with  the  equipment  in  April  1965--2  months 
late. 

Comment:  The  use  of  COBOL  61  in  the  inquiry  system  proved  to  be  inefficient,  resulting  in  sev¬ 
eral  programs  being  partially  rewritten  in  ARGUS,  the  assembly  and  macro  language.  The 
COBOL  61  compiler  also  had  some  bugs  which  were  corrected  by  Honeywell  personnel. 

Honeywell  is  responsible  for  the  maintenance  of  the  software. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  Personnel  Data  Systems  Division  of  the  Mili¬ 
tary  Personnel  Center  was  responsible  for  the  development  of  PDSO/MAC.  Twenty  experienced 
programmers  were  assigned  the  system  analysis  and  programming  tasks  required  for  PDSO/ 
MAC  development.  These  personnel  were  divided  into  one  team  responsible  for  file  maintenance 
programs  and  another  team  responsible  for  development  of  file  inquiry  programs. 

System  design  of  PDSO/MAC  required  close  coordination  with  PDSO/MPC  and  the  CBPO 
systems,  since  these  systems  are  all  part  of  the  AF  vertically  integrated  personnel  data  system. 
All  three  systems  work  with  the  same  data  elements  and  thus  consistency  in  format  and  handling 
had  to  be  maintained  across  development  of  these  systems.  PDSO/MAC  system  design  com¬ 
menced  prior  to  the  selection  of  the  H800/200  computer  hardware.  The  system  designers  had 
assumed  a  variable  word  length  machine  concept  which  required  reorientation  on  the  selection 
of  the  H800. 

The  system  was  programmed  in  COBOL  61;  however,  the  inquiry  system  proved  inef¬ 
ficient  and  parts  of  several  programs  were  subsequently  rewritten  in  ARGUS  assembly  language 
by  Honeywell  personnel.  Program  and  system  documentation  conformed  to  standards  specified 
in  AFM  171-10.  PDSO/MAC  was  given  a  thorough  system  test  by  simulating  inputs  typical  of 
SAC,  TAC,  and  ADC. 


FILE  CONVERSION:  A  separate  organizational  entity  was  created  to  plan  the  file  conversion  ac¬ 
tivities.  The  conversion  consisted  mainly  of  changing  formats  and  codes  to  conform  with  the 
vertically  integrated  system.  Much  interfacing  with  MPC  and  CBPO  existed.  Media  included 
both  cards  and  tapes.  A  team  of  four  was  used  for  12  months  to  do  the  planning,  programming, 
and  interfacing.  Two  thorough  documents  were  produced  specifying  procedures  for  MAC's  and 
CBPO's.  These  procedures  spelled  out  in  detail  the  flow  of  information,  the  changes  in  codes, 
the  media  used,  the  responsible  organizations,  pre-  and  post-conversion  activities,  the  timing 
of  conversion,  and  the  audits  and  checks  to  be  applied.  In  addition,  the  team  oriented  MAC  and 
CBPO  personnel  on  these  procedures  through  personal  visits  to  the  sites.  The  conversion  was 
accomplished  very  smoothly.  The  computer  time  used  was  not  identifiable  and  is  included  in 
the  checkout  hours. 
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DOCUMENTATION:  The  system  is  documented  in  AFM  30-3  and  according  to  standards  specified 
in  AFM  171-10. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Yearn 

Sampled 

Allocated  to 
System 

In  ADP 

In  l’ereonnel 
Syatemn 

Of  College 

Development 

Manager 

3 

3 

1 1.0 

7.5 

3.5 

Analyst 

7 

7 

8.0 

14.5 

Unknown 

Prog  rammer 

18 

18 

9.5 

4.0 

U  nknown 

Ope  rations 

Manager 

None 

2 

Unknown 

Unknown 

Unknown 

Operator 

54 

7 

6.0 

2.0 

IxT 

OPERATIONS:  All  scheduling  for  the  computer  operation  is  automated  with  monthly  and  daily 
schedules  being  updated  and  generated  at  fixed  intervals  by  the  H800/200  computers.  The  oper¬ 
ation,  a  closed  shop,  is  staffed  as  required  by  workload. 

Comment:  The  II800  is  currently  overloaded  at  SAAMA.  It  is  planned  to  augment  the  present 
computer  configuration  with  another  H800. 


6?  hr.  9f 


Sc  h«l  Mt 
59  hr.  8f 
Mach  Krror  l.o.t 
*  hr.  If 
Un.cliri  Mt 
9  hr.  If 


Prod  (all  app.) 
248  hr.  Mf 


Prrp  (all  appal 
I  hra  If 


Chg  Lo.t  (all  other  app.) 

38  hr.  5f 


Pro#  l)rv  *  Mt  (all  appa) 

91  hr.  I2f 

Ch(  l.o.t  (all  app.) 

4  I  hr.  hf 


Prod  I  PDSO/MAC  app) 

89  hr.  I2f 

Prrp  (I'DSO/MAf.  *,»>) 

2  hr.  If 

roK  Ilrv  *  Mt  (IMl.Sn/MAC  app) 
H  hra  2  ' 

Pfrvl  (all  otlii  r  app.) 

184  hr.  24f 


Prep  (all  other  app.) 

1  hr  If 

/  'Pro#  Dev  ♦  Mt  (all  other  app.) 
HI.  hr.  in 


1-liK  I  ><*.t  (PDSO/MA( 
9  hr.  If 


«PP) 


APPLICATION  PH  OCR  AM  MAINTENANCE:  All  program  maintenance  of  the  basic  PDSO  system 
is  doncT  by  the  Pe  r sonne  1  Data  Systems  Division  at  the  Military  Personnel  Center.  However, 
since  the  MAC  computers  (H800/200  system)  may  differ  from  one  another  in  configuration,  the 
personnel  at  each  MAC  retrofit  the  basic  PDSO  system  to  their  own  computer  configuration. 
Furthermore,  the  MAG's  may  develop  command-unique  "add-ons"  for  their  installation.  All 
development  programmers  and  analysts  were  phased  into  program  maintenance.  Maintenance 
consists  of  60  percent  program  improvements  and  40  percent  corrections.  Programmers  re¬ 
ceive  from  one  checkout  run  per  day  to  two  or  three  per  week.  Dolling  AFD  is  often  used  for 
program  testing  because  of  its  light  computer  load. 

Comment:  None. 
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BENEFITS;  Proposed;  PDSO/MAC  was  proposed  to  be  the  major  air  command  element  of  a 
three-level,  vertically  integrated  personnel  data  system  for  officers.  Specific  benefits  that 
PDSO/MAC  was  to  provide  include  increased  responsiveness  to  commanders  and  management 
in  the  creation,  edit,  control,  retrieval,  distribution,  and  display  of  active  duty  officer  person¬ 
nel  data.  Other  benefits  were  to  be  the  standardization  of  personnel  systems  across  all  major 
air  commands  and  significant  cost  reduction  in  personnel  data  handling. 

Actual;  PDSO/MAC  has  provided  increased  responsiveness  to  commanders  and  management 
In  the  creation,  edit,  control,  retrieval,  distribution,  and  display  of  personnel  data.  Person¬ 
nel  systems  were  standardized  across  major  air  commands  and  standard  data  elements  were 
adopted  throughout  the  vertically  integrated  system. 


COST  FACTORS; 


Man-Montha  of  Davclopmant  Effort  (Dev.) 

Proposed  Unk  CZ 

Actual:  489 

Comment:  No  formal  DAP  wai  praparad  for  PDSO/MAC.  Its  developmant 
wai  recognised  aa  a  part  of  the  overall  vertically*  Integrated  PDSO. 

Montha  of  Elapsed  Development  Time  (Dev.) 

Propoaed:  link  CZ 

Actual:  22 

Comment:  PDSO/MAC  eystem  design  commenced  in  March  1964.  The 
ayatem  waa  declared  operational  at  ATC  on  1  December  1965. 

Dollars  of  Hardware  Coat  for  Program  Checkout  <Dev.) 

Propoaed'  Unk  CZ 

Actual:  84,700 

Comme  nt:  1,  300  houra  war*  uaed  for  program  c  heckout.  The  number  of  hour  a 
include  a  an  unknown  number  of  hour  a  required  for  file  conver  a  Ion.  Approxi¬ 
mately  100  of  the  1,300  hour  s  were  uaed  at  iocatlona  other  than  ATC'a  H800. 

Hours/Month  of  Hardware  Uae  for  Application  Production  (Op.) 

Propoaed:  Unk  CZ 

Actual:  89  ■■■HH 

Comment:  The  actual  number  reflecta  uaage  during  March  1966  on  the 
Honeywell  800  computer.  PDSO/MAC  application  production  uaage  la 
not  known  for  the  Honeywell  200  computer 


Houra/Month  of  Hardware  Uae  for  Program  Maintenance  (Op.) 

Propoaed:  Unk  CZ 

Actual:  14 

Comment:  The  actual  number  reflecta  uaage  during  March  1966  on  the 
Honeywell  800  computer.  PDSO/MAC  program  maintenance  uaage  la  not 
known  for  the  Honeywell  200  computer. 

Number  of  Operatlona  Peraonnel  (Op.) 

Propoaed:  Unk  CZ 

Actual:  7 

Comment:  The  actual  number  of  peraonnel  la  prorated  from  21  operator  a 
allocating  approximately  30  percent  of  their  time  to  PDSO/MAC, 

Number  of  Program  Maintenance  Peraonnel  (Op. ) 

Propoaed:  Unk  CZ 

Actual:  9 

Comment:  The  actual  number  of  peraonnel  repreaents  original 
development  peraonnel. 

Dollara /Month  of  Hardware  Coat  (Op.) 

Propoaed:  Unk  CZ 

Actual:  10,457 

Comment:  None. 


FUTURE  PLANS;  The  current  machine  configuration  is  overloaded  and  does  not  supply  the  Mili¬ 
tary  Personnel  Center  adequate  checkout  time  for  its  function  as  centralized  development  and 
maintenance  organization  for  PDS-O  65.  It  is  planned  to  augment  the  present  configuration  with 
another  H800.  Sufficient  H200  capacity  is  available  to  serve  both  processors. 
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SYSTEM:  Personnel  Data  System-Officers,  Military  Personnel  Center- -PDSO/MPC 
(Burroughs  5500) 


DATA  SYSTEM  DESIGNATOR:  E053  and  El 01 A 


DATA  COLLECTION  DATE:  March  1966 


Contact  for  Additional  Information 

Air  Force  Military  Personnel  Center 
Randolph  Air  Force  Base 

San  Antonio,  Texas 

Development 

Air  Force  Military  Personnel  Center 
Randolph  Air  Force  Base 

Texas 

Maintenance 

Air  Force  Military  Personnel  Center 
Randolph  Air  Force  Base 

Texas 

Pilot  Installation 

None 

First  Operational  Installation 

Air  Force  Military  Personnel  Center 
Randolph  Air  Force  Base 

Texas 

Number  of  Operational  Installations 

1 

FUNCTION:  The  users  of  PDSO/MPC  are  the  Directorates  of  Personnel  Services,  Personnel  Re¬ 
sources  and  Distribution,  and  Personnel  Program  Action,  USAF  Military  Personnel  Center.  A 
commonmission  of  the  users  is  the  maintenance  of  personnel  data  such  as  as signments,  accessions, 
separations,  promotions,  and  integrations.  PDSO/MPC  functions  as  a  management  support  system 
to  maintain  a  central  file  of  personnel  data  on  all  active  Air  Force  officers.  Other  important  func¬ 
tions  of  the  system  include  maintaining  manning  data  on  Air  Force  organizations  by  grade  and  func¬ 
tional  category,  and  Personnel  Accounting  Symbols  for  all  Air  Force  units.  An  on-line  inquiry  ca¬ 
pability  enables  the  Military  Personnel  Center  staff  to  have  access  to  certain  data  within  90  seconds. 

ORGANIZATION: 
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HISTORY:  PDSO-65  evolved  from  PDSO-63,  an  automated  personnel  system  operated  at  Head¬ 
quarters,  USAF.  A  need  to  integrate  the  personnel  data  systems  vertically  at  Headquarters, 
USAF ,  the  major  air  commands  (MAC's)  and  consolidated  base  personnel  offices  (CBPO's)  gave 
impetus  to  the  development  of  the  system.  In  addition,  a  direct  inquiry  capability  was  to  be  in¬ 
cluded  in  the  new  system.  The  hardware  configuration  was  selected  by  the  EDP  Equipment  Of¬ 
fice  (ESQ).  All  development  work  was  done  at  the  USAF  Military  Personnel  Center  (MPC). 

A  planning  group  of  personnel  from  all  major  users  of  the  system  and  other  related  sys¬ 
tems  was  established  to  outline  the  areas  of  PDSO-63  requiring  redesign.  The  development  was 
broken  down  into  two  primary  areas:  (1)  design  and  documentation  of  specifications,  and  (2) 
programming  and  system  implementation.  Both  of  these  major  areas  were  broken  down  into 
tasks  and  the  responsibility  for  these  tasks  was  delegated.  Standards  for  programming,  docu¬ 
mentation,  and  management  control  were  also  specified. 

The  Directorate  of  Personnel  Systems  had  overall  responsibility  for  the  redesign  of 
PDSO-63  and  the  implementation  of  PDSO-65  at  the  Military  Personnel  Center.  The  entire  per¬ 
sonnel  resources  of  the  CBPO  Division,  MAC  Division,  MPC  Division,  and  the  Plans  and  Ad¬ 
ministration  Office  were  assigned  to  the  effort.  In  addition,  partial  support  was  supplied  by 
the  Systems  Development  Division.  Limited  resources  were  available  in  other  directorates  of 
the  USAF  Military  Personnel  Center  and  directorates  of  Headquarters,  USAF. 

An  extensive  set  of  documents  exist  describing  the  system  objectives,  processing,  and 
data  element  formats.  The  documentation  is  oriented  toward  the  total  vertical  personnel  sys¬ 
tem,  since  users  (suppliers  of  input  to  PDSO/MPC)  will  be  lower  level  subsystems  in  the  ver¬ 
tical  structure. 


SCHEDULE: 


CY  1965 


!  CY  1966 


CY  1968 
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II 
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▲  Actual  Date 
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m  Hardware  Propoaal  Evaluation  |  J 
A  PDSO-65  Impiemented  on  IBM  7080/1401  at  Pentagon 
A  B5000  Award  Announced  |  |  j  |  |  J  |  |  J 

APDSA  Dropped  for  B5000  Became  PDSO-63  Could  Not  Be  Converted  Directly 
I  1  [a  PDSO-65  Sy*tem  Specification  Written 


* 
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System  Te*t 
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DATA  BASE 

Char,  in  Data  Baae: 

276.700,000 

Percent  of  Char,  on  D/A  Storage: 

86 

Mlllieeconda  of  Acceaa  Time  for  D/A: 

20 

No.  of  Data  Baae  Record  Typea: 

6 

No.  of  Data  Baae  Recorde: 

544,500 

Percent  Growth  Rate  /Mo.  x 

1.1 

Char.  /Mo.  of  Update  Input: 

45,850,000 

WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char.  /Mo.  of  Input 

Volume: 

46.460.000 

No.  o f  Input  Traae- 

action  Typea: 

122 

No.  of  Input 

Data  Fielda: 

681 

Percent  of  Input 

Rejecta: 

4.3 

Key 

100% 

90 

SO 

70  S 
60  § 

SO 
40 

30  ^ 

20 
10 
0% 


•»  _  C 

Is  cl 


t 

<s 


i  t 
I  id 
3  23 


t 


nil 


■i A-li 


Ihn 


Total  Source  Inatructione: 
Total  Object  Instnactione: 
Hra.  /Mo.  of  Application 
Production: 


Baae  Compute  r(  a) 

195.100 

780.S00 


Peripheral 
Compute  r(  a) 

NA 

NA 


Char.  /Mo.  of  Out* 

put  Volume: 

81,600,000 

No.  of  Output 

Formate: 

141 

Reaponae  Time 

(aeconda): 

90.0 

HARDWARE: 
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Ci 

ird  Read 
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SOFTWARE:  Software  for  the  Burroughs  5500  consisted  of  COBOL  and  ALGOL  compilers,  an 
ESPOL  assembler,  hardware  diagnostic,  debugging  aids,  and  a  Master  Control  Program  (MCP), 
No  utility  routines  were  supplied  by  Burroughs,  but  some  were  obtained  from  the  Burroughs 
user  group.  The  software  was  delivered  by  Burroughs  with  the  equipment  in  February  1965. 

Comment:  The  initial  COBOL  compiler  lacked  many  desired  features  (e.  g.  ,  disk  constructs, 
sort  and  merge  verbs).  A  COBOL  compiler  with  the  disk  constructs,  the  sort  verb,  and  merge 
verb  (which  still  gives  problems)  was  delivered  in  May,  1965.  Program  checkout  with  COBOL 
was  difficult  because  of  no  run  time  patching  or  modification  capability  and  the  absence  of  an 
intermediate  or  assembly  language  output  to  aid  in  the  analysis  of  programs.  The  programmers 
also  felt  that  more  extensive  diagnostic  messages  from  the  COBOL  compiler  would  have  assisted 
program  development.  ALGOL  diagnostics  were  felt  to  be  adequate.  The  compilers  and  assem¬ 
bler  were  on  the  whole  highly  successful  and  contributed  to  system  development. 

MCP  was  converted  to  operate  with  the  disk  construct  in  May,  1965.  The  users  feel  that 
checkpoint  and  restart  capability  should  be  on  a  controlled  basis  rather  than  periodic.  The  pri¬ 
mary  attribute  of  MCP  that  assists  effective  operation  is  the  automatic  scheduling  of  jobs  and 
I/O  assignments,  which  achieves  efficient  peripheral  device  utilization.  The  rigid  structure  of 
MCP  does  not  allow  easy  modification  for  handling  nonstandard  formats,  such  as  tapes  of  differ¬ 
ent  labeling  format.  MCP  is  used  to  maintain  the  application  program  library  and  to  call  all 
functional  programs  from  this  library. 

It  was  felt  that  the  channels  for  dissemination  of  information  on  the  software  and  correc¬ 
tion  of  errors  were  generally  not  responsive  to  the  requirements  of  the  system  users.  The 
program  documentation  was  usually  delivered  much  later  than  the  software  itself  and  was  some¬ 
times  inconsistent  with  the  software. 

Representatives  of  the  manufacturer  are  maintained  on  site  to  assist  with  any  problems 
in  the  support  software.  In  addition,  several  AF  personnel  have  been  trained  in  the  maintenance 
of  the  operating  system  and  compilers.  The  systems  programming  people  are  also  involved  in 
making  recommendations  for  modifications  to  improve  the  efficiency  of  the  system  operation. 

APPLICATION  PROGRAM  DEVELOPMENT:  A  planning  group  of  personnel  from  all  major  users 
of  the  PDSO-6 3  system  outlined  the  redesign  of  PDSO-63.  The  same  group  also  provided  the 
design  specification  documentation,  programming  standards  and  system  implementation  of 
PDSO-65.  The  programming  effort  was  divided  into  two  areas:  (1)  file  maintenance,  and  (2)  file 
retrieval.  There  are  74  distinct  file  maintenance  programs,  which  were  written  in  COBOL. 
There  are  80  file  retrieval  programs  written  in  COBOL  in  addition  to  the  on-line  retrieval  pro¬ 
grams,  which  were  written  in  ALGOL  for  efficiency  of  operation.  Each  program  was  checked 
out  individually  prior  to  the  systems  test.  No  program  patching  capability  was  available.  This 
caused  an  inordinate  amount  of  checkout  time  to  be  used  for  recompilation.  The  complete  sys¬ 
tem  test,  designed  to  fully  exercise  the  assignments,  promotions,  separations  and  integration 
of  subsystems,  was  planned  and  completed  on  schedule. 


FILE  CONVERSION:  The  file  conversion  activity  was  documented  and  was  planned  for  execution 
between  6  and  12  October  1965.  A  flow  chart  was  drawn;  all  master  files  and  intermediate  work 
files  of  the  PDSO  system  were  specified  and  file  formats  and  record  contents  indicated. 

While  7080/1401  tapes  were  compatible  with  B5500  tapes,  COBOL  (135500)  would  only 
process  Burroughs  tandard  labels,  and  consequently  tape  labels  on  original  tapes  had  to  be  mod¬ 
ified  accordingly  before  conversion.  Necessary  programs  were  prepared.  A  total  of  29  files 
were  converted.  These  were  systematically  analyzed  and  the  volume  indicated  by  the  number 
of  reels,  records,  blocks  per  record,  and  characters  per  block  for  each  file. 

Computer  time  used:  approximately  60  hours. 
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DOCUMENTATION:  User  documentation  is  aimed  at  those  who  supply  input  at  the  lower  level  in 
the  vertical  structure.  Other  documentation  includes  system  design  review  notes,  program 
changes,  etc.  A  folder  is  maintained  for  each  program  containing  listings,  flow  charts,  and 
program  specifications. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Personnel 
Systems 

Of  College 

Development 

Manager 

15 

15 

8.5 

7.0 

3.5 

Analyst 

7 

7 

4 

11.5 

U  nknown 

Programmer 

37 

40 

7.0 

5.5 

Unknown 

Operation* 

Manager 

3 

3 

12.0 

2.5 

2.0 

Operator 

29 

52 

4.5 

0.5 

X 

OPERATIONS:  The  computer  operation  is  staffed  24  hours  a  day,  7  days  a  week.  It  operates  as 
a  closed  shop.  PDSO/MPC  is  the  only  application  on  the  Burroughs  5500  computer.  Immediate 
queries  are  processed  on-line  during  normal  working  hours  5  days  per  week  in  a  multiprogram¬ 
ming  mode  with  scheduled  runs.  Deferred  inquiries  and  file  maintenance  are  run  at  other  times 
according  to  a  master  schedule. 

Comment:  Program  development  and  maintenance  time  is  somewhat  large  due  to  lack  of  pro¬ 
gram  patching  capabilities.  A  large  percentage  (21  percent)  of  time  is  taken  for  computer 
maintenance  and  machine  error  lost  time,  reflecting  low  hardware  reliability. 


Other 
27  hr s  4 f 
Off 

23  hrs  3$ 
Schd  Mt 
79  hrs  lift 

Mach  Error  Lost 
45  hrs  6$ 


Prep 
14  hrs  2% 


APPLICATION  PROGRAM  MAINTENANCE:  There  are  currently  36  programmers  and  14  system 
analysts  involved  in  program  maintenance  for  PDSO/MPC,  all  of  whom  were  involved  in  the  de¬ 
velopment  efforts.  The  program  maintenance  activity  is  divided  among  corrections  to  programs, 
system  documentation,  system  improvements,  and  program  operational  efficiency  improvements. 

Comment:  The  large  amount  of  time  devoted  to  the  program  maintenance  effort  is  mainly  due  to 
the  fact  that  a  completely  new  system  has  not  been  operational  very  long  and  problems  are  still 
being  encountered  in  the  software. 


Unschd  Mt 
29  hrs  4$ 
Idle, 

.  27  hrs  4% 

Set  Up, 
22  hrs  3% 
Chg  Lost 
20  hrs  3% 
Prog  Dev  &  Mt 
68  hrs  9% 


Burroughs  5500 


Prod  (PDSO  MPC 
only  app)  376  hrs  51% 
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B ENEFITS;  Proposed:  The  PDSO/MPC  was  established  along  with  the  USAF  Military  Person- 
neT Center  by  direction  of  the  Secretary  of  the  Air  Force.  Prior  to  PDSO/MPC,  Air  Force  Hq. 
personnel  processing  was  performed  on  an  IBM  7080  at  the  Pentagon.  The  PDSO/MPC  system 
was  to  provide  a  number  of  new  benefits,  including  (1)  inclusion  of  significant  additional  data 
on  each  Air  Force  officer;  (2)  standardization  of  data  codes  and  formats  to  enhance  efficient 
communications  of  personnel  data  from  one  AF  personnel  system  to  another;  and  (3)  immediate 
access  to  personnel  data  for  personnel  managers. 

Actual:  PDSO/MPC  became  operational  in  October  1965.  It  provided  the  additional  officer  data 
and  standardization  of  data  codes  that  was  required.  Communications  with  other  AF  personnel 
systems  were  enhanced,  since  PDSO/MPC  was  designed  as  the  top  component  of  a  three-le\ol, 
vertically  integrated  personnel  system.  Remote  immediate  access  terminals  were  provided. 
However,  due  to  the  saturated  computer  utilization,  updates  could  be  run  only  three  times  weekly 
(compared  with  a  proposed  daily  update),  thereby  causing  personnel  data  to  be  less  current  than 
originally  proposed.  This  problem  is  presently  being  alleviated  by  procurement  of  additional 
hardware  modules  for  the  system. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev,) 

Proposed:  Unk  CZ 

Actual:  1,443  MBM 

Comment;  No  formal  DAP  was  prepared  for  PDSO/MPC.  An  advanced 
design  team  bogan  work  in  May  1963  to  eatabliah  objectivea  and  equip- 
ment  requirements  for  PDSO  65.  This  effort  evolved  Into  the  PDSO  65 
Bystem  design  begun  in  April  1964. 

Montha  of  Elapsed  Development  Time  (Dev.) 

Proposed  161  1 

Actual:  2( 

Comment:  A  proposed  date  for  PDSO  65  implementation  waa  eatabliahed 
ty  the  PDSO  65  design  team  aa  July  1965.  Because  of  late  delivery  of  the 
MAC  Honeywell  800/200  computers,  the  implementation  of  PDSO  65  waa 
delayed  until  November  1965. 

Dollars  of  Hardware  Coat  for  Program  Checkout  (Dev.) 

Proposed:  UnkCZ 

Actual:  Unk  K 

Comment:  Computer  tune  used  before  the  acceptance  of  the  computer  on 
T  M* v  I  /05  was  no*  logged.  After  acceptance,  it  la  known  that  at  least 
1,112  hours  were  used  for  program  checkout  between  May  and  September 
1965,  coating  approximately  $266,880.  Program  checkout  waa  lengthened 
because  of  the  excessive  recompilation  required  due  to  inadequate 
program-patching  capabilities  with  COBOL. 

Houra/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed;  Unk  CZ 

Actual:  37'  ■■■■■■■■■■■ 

Comment:  Peflecta  usage  during  February  1966  on  the  Burrougha  B5500 
computer. 


FUTURE  PLANS:  Excessive  workload  on  PDSO/MPC  has  resulted  in  degradation  of  system  per- 
formance  (master  files  are  only  updated  three  times  weekly  as  opposed  to  a  planned  daily  update). 
Proposed  improvements  in  the  hardware  configuration  to  handle  the  workload  include;  (1)  in¬ 
crease  the  number  of  modules  from  six  to  eight  and  increase  memory  speed  from  6  \is  to  4  ps; 

(2)  add  another  central  processing  unit;  (3)  increase  the  number  of  tape  drives  from  8  to  14;  .and 
(4)  increase  the  number  of  disk  storage  modules  from  25  to  32,  giving  307.2  million  characters 
of  disk  storage  instead  of  240  million.  At  this  time,  there  are  no  major  design  changes  contem¬ 
plated  for  PDSO/MPC  system  programs. 


Houra/Month  of  Hardware  Use  for  Program  Maintenance  (Op.) 

Proposed:  Unk  CZ 

Actual:  68 

Comment:  Reflects  usage  during  February  1966  on  the  Burrougha  B5500 

computer. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  UnkGL 

Actual:  5< 

Comment:  The  actual  number  of  personnel  represents  operators  at  the 

Military  Personnel  Center. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  UnkCZ 

Actual:  50 

Comment:  The  actual  number  of  personnel  consists  of  14  analysts  and 
programmers . 

Dollar  s /Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  C2 

Actual:  64.78(1 

Comment:  None. 
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SYSTEM:  Regional  Accounting  and  Finance  Test--RAFT  (RCA  301) 


DATA  SYSTEM  DESIGNATOR:  H060 
DATA  COLLECTION  DATE:  April  1966 


Contact  for  Additional  Information 

ATAAF  Accounting  and  Finance  Dir. 
ATADC-DCS/Comptroller 

Randolph  Air  Force  Base 

San  Antonio,  Texas 

Development 

Randolph  Air  Force  Base,  Texas 

Sheppard  Air  Force  Base,  Texas 

Maintenance 

Sheppard  Air  Force  Base 

Texas 

Pilot  Installation^ 

Sheppard  Air  Force  Base 

Texas 

First  Operational  Installation^ 

Sheppard  Air  Force  Base 

Texas 

Number  of  Operational  Installations 

1 

Note:  (1)  Entire  system  was  a  pilot  system  deactivated  in  June  1965. 


FUNCTION:  The  users  of  RAFT  are  the  Base  Accounting  and  Finance  Offices  at  Sheppard, 
Reese,  Vance,  and  Webb  Air  Force  Bases.  The  mission  of  the  users  is  to  perform  the  ac¬ 
counting  and  finance  functions  for  their  respective  bases.  RAFT  functions  as  a  research  and 
development  support  system  in  that  it  is  the  result  of  a  pilot  project  to  design,  develop,  and 
test  a  standard  USAF  base  level  regional  a ccounting  and  finance  system  (excluding  military 
pay),  utilizing  electronic  data  processing  equipment.  RAFT  was  deactivated  in  June  1965. 


ORGANIZATION: 


Function*!  Responsibility 
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HISTORY:  The  Air  Training  Command  (ATC)  was  requested  by  Headquarters  USAF  to  investi¬ 
gate  the  development  of  a  small  regional  accounting  and  finance  system.  An  ATC  planning 
group  was  formed  that  developed  general  project  concepts  and  an  agenda  for  a  meeting  with 
representatives  of  Headquarters  USAF.  This  meeting  was  held  in  March  1962  and  an  action 
schedule  was  developed  encompassing  the  concept  preparation,  system  design,  programming, 
testing,  and  evaluation.  Development  took  place  at  Randolph  AFB.  RAFT  became  operational 
at  Sheppard  AFB  in  December  1963  and  later  at  Reese  AFB,  Vance  AFB,  and  Webb  AFB. 

The  system  was  designed  as  a  test,  and  the  test  was  successfully  completed.  RAFT  was  de¬ 
activated  in  June  1965  due  to  loss  of  computer  support. 

Data  systems  analysts  assigned  to  the  project  had  extensive  background  and  training  in  a*  - 
counting  and  finance,  whereas  their  training  in  system  design  with  EDP  equipment  was  not  as 
extensive.  Data  systems  programmers  assigned  to  the  project  had  no  previous  programming 
experience  or  instruction  in  programming  and  were  sent  to  RCA  301  programming  school. 

The  team  concept  was  employed  in  development,  with  a  team  consisting  of  a  functional  expert 
in  the  accounting  and  finance  area,  an  analyst,  and  a  programmer.  Critical  path  scheduling 
and  progress  reporting  techniques  were  used  throughout  the  development  of  RAFT. 


SCHEDULE: 


j"jr  mIaIJTjIa  s|on  i) 


.1  h  |M]  X C  l  J  J  A  ‘‘  O  N  I)  J  F  M  A  M  J  J  A  S  ON  D 


JKMAMJ  J  A  S  O  N  P  J  h  M  A 


M  A  M  J  J  A  S  O  Nil) 


rmitir 

A  Actual  Date 


HQ  USAF  Solti ited  ATC  Interest  in  Reft 

111 . .  i  I  I  |  I  It  II 

4  ATC  Accepted  end  Formed  Planning  Grou 

A  Pilot  Project  Authorised  I  I  I  I 
±  l  I  »  l  t  t  l  i  •  I  I  II 
—  k Plan  and  Concept*  Prepared  | 


O  Planned  Dale 


|  ■  |  ■  |  ■  j1  |  j  ^  System  Design 
A  Systems  and  Programming  Cl. 


Proposal  Stage 

1 .1.1.1. 1 .1  I. 


„  M  II  I  I 

Programming 


i  i  <  i  i 


Ajest  and  Debug  at  HEW,  Wash. 

A^RCA  301  Installed  at  Sheppard  AFR 

Test  and  Debug  at  Sheppard 


Development  Stage 

I  I  II  I  I  I  I  I 


4<j)  F.v.lu.jlo,,  |  |  I  I  I 

Sheppard  Operational  j 
J  r“  ^  k  J  Other  Sites  C 


Operation* 


Operational  Stage 

I  I  I  I  I  I  I  I 


4  Rtlt  Deaitivaied 
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DESCRIPTION:  The  RAFT  system  functions  are  Civilian  Payroll,  Travel  and  Transportation 
(processing  of  open  accounts  on  individual  travelers),  Commercial  Services  (processing  of 
procurement  functions),  Reimbursements  (maintenance  of  customer  accounts),  and  Accounts 
Control  (update  of  commitment  and  obligation,  MAFR,  check  payment,  and  accountability 
records).  Financial  input  information  is  sent  to  the  regional  office  (Sheppard  AFB),  and  the 
accounting  and  finance  offices  of  the  four  bases  (the  users)  receive  in  return  products  for  base 
and  employee  use.  These  include  payroll  vouchers,  payroll  checks  and  bonds,  printouts  of 
status  of  open  accounts,  and  various  budget  reports. 


R.c.lv.4  From 
Bt.«  vt.  AUTODIN 
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DATA  BASE 

Char.  In  Data  Base: 

17,510.000 

Percent  of  Char,  on  D/A  Storage 

NA 

Milliseconds  of  Access  Time  for  D/A: 

NA 

No.  of  Data  Base  Record  Types: 

• 

No.  of  Data  Base  Records: 

135,500 

Percent  Growth  Rate/Mo.  : 

Unk 

Char.  /Mo.  of  Update  Input: 

6.402.000 

WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char. /Mo.  of  Input 

Volume: 

6,402,000 

No.  of  Input  Trans¬ 

action  Types: 

48 

No.  of  Input 

Data  Fields: 

227 

Percent  of  Input 

Rejects: 

0.8 

Key 


t 

s 


5  2 

o.  c  t 

t?  O  O 


100% 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0% 


Total  Source  lnetructlona. 
Total  Object  Inat ructions: 
Mrs, /Mo.  of  Application 
Production. 


OUTPUTS 


Hi  „  Jr 

i  it 

A 

■Si  M  ■ 

lLh 

Rase  Compute r(») 

34.620 

34.620 


Peripheral 
Compute  r(e) 

NA 

NA 


Char.  /Mo.  of  Out* 
put  Volume:  26,070,000 

No.  of  Output 
Formate:  57 

Reaponee  Tima 
(aeconde):  NA 


HARDWARE: 


Console 


RCA  304 

IBM  1402 

Central 

Card 

Processing 

Reader/ 

Unit 

Punch 

RCA  316-1 
■  Printer 

RCA  333 

Control 

Printer 

RCA  318 

Hi-Data 

Control 


RCA  319 

Hi-Data 

Control 


RCA  301 


Com¬ 

puter 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Internal  Storage 

External 

Storage 

Peripheral  Devices 

Card  Reader/Punch 

Printer 

Add 

Time 

(us) 

Cycle 

Time 

(us) 

Char. 

Size 

(bits) 

Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapes 

T  rans. 
Rate 

No. 

Read 
Speed 
(cards / 
min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

(ipm) 

RCA 

301 

2/61 

Char. 

98 

7 

6 

20K 

6- 

38lU> 

10K  to 
66K 

1- 

1402 

800 

250 

1- 

333 

L000 

Comment:  (1)  Housed  in  one  cabinet. 
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SOFTWARE:  Software  for  the  RCA  301  consisted  of  the  following:  (1)  a  symbolic  assembly 
language  assembler;  (2)  a  Utility  Service  Reference;  (3)  a  '’consolidate,1'  (4)  a  Test  Library 
Tape  (TLT)  and  Program  Library  Tape  (PLT);  and  (5)  a  sort  program.  The  software  was 
delivered  by  RCA  with  the  equipment  in  June  1963. 

Comment:  "Consolidate"  provides  for  selective  dynamic  memory  dumps  and  traces.  A  routine 
was  added  by  the  Chief  Programmer  on  the  RAFT  project  to  TLT  and  PLT  to  provide  for  run-to- 
run  operating  instructions.  There  have  been  no  formal  system  programming  activities.  An 
RCA  system  representative  provided  software  support. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  responsibility  of  RAFT  was  balanced  between 
two  USA F  elements  of  the  Accounting  and  Finance  Directorate  and  the  Data  Automation 
Directorate.  The  former  established  policy  and  described  output  demands  on  the  system.  The 
latter  designed  and  developed  the  ADP  system.  The  system  design  phase  included  detailed 
flow  charts,  input/output  requirements,  stored  data  requirements,  and  transaction  codes  to  be 
used  in  operations.  The  programs  were  written  in  COBOL  by  programmers  trained  at  the 
RCA  301  programming  school.  Due  to  the  300-mile  distance  between  the  programming  loca¬ 
tion  and  the  checkout  computer,  the  checkout  was  not  begun  until  programming  was  virtually 
completed.  RCA  provided  90  hours  of  free  test  time  during  the  461 -hour  checkout,  the  amount 
of  checkout  time  was  high  due  to  machine  and  tape  malfunctions.  Special  input  data  was  de¬ 
veloped  for  program  checkout.  Computer  time  was  supplied  by  open  shop  operations  with  pro¬ 
grammers  getting  as  many  as  five  runs  per  day.  System  tests  also  consisted  of  parallel  oper¬ 
ations  after  completion  of  all  program  testing  and  debugging.  Critical  path  scheduling  using 
LESS  (Least  Cost  Estimating  and  Scheduling)  and  weekly  progress  reporting  using  PROMT 
(Planning  and  Progress  Measurement  Techniques)  were  the  management  control  methods  used. 


FILE  CONVERSION:  Conversion  procedures  to  be  used  by  the  bases  in  converting  their  man- 
ual  records  to  RAFT  input  formats  were  developed  by  RAFT  project  personnel  within  the 
applicable  subject  matter  areas.  During  the  conversion  period,  RAFT  project  and  accounting 
and  finance  personnel  visited  each  base  and  were  on  hand  to  assist  them  with  any  problems  en¬ 
countered  in  converting  their  records.  The  conversion  was  from  manual  records  to  punched 
cards.  The  punch  card  information  was  sent  to  the  region  via  AUTODIN  and  received  at  the 
regional  office  in  the  form  of  punched  cards.  No  major  problems  were  encountered  in  base 
conversions.  A  problem  did  arise  when  it  was  discovered  that  the  AUTODIN  equipment  at 
the  bases  could  not  send  or  receive  credit  zeros.  This  problem  was  eliminated  by  equipment 
modification.  Each  base  was  converted  by  functional  area  which  reduced  confusion  and  per¬ 
mitted  an  orderly  flow  of  data  into  the  region  office.  This  gave  region  office  personnel  ade¬ 
quate  time  to  load  and  audit  the  input  data.  No  special  programming  was  required. 
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DOCUMENTATION:  User  documents  as  well  as  system  design  specifications  were  produced  by 
the  system  designers  during  the  system  design  phase.  Flow  charts  were  produced  prior  to 
coding.  All  deviations  from  these  flow  charts  are  documented  on  program  change  forms  during 
the  coding,  check,  and  maintenance  phases.  AFL  177-3,  Terminal  Documentation  Parti  con¬ 
tains  the  General  Systems  Specifications  and  Part  II  contains  the  Evaluation  Schedules. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
Syatem 

In  ADP 

In  Accounting 

Of  College 

Development 

Manager 

3 

3 

1.0 

11.0 

3.0 

Analyst 

7 

7 

2.0 

7.0 

Unknown 

Programmer 

14 

14 

1.5 

0 

Unknown 

Operation! 

Manager 

1 

0.6 

9.0 

0 

3.0 

Operator 

4 

2.4 

5.0 

0 

OPERATIONS:  RAFT  was  run  during  the  second  shift  at  Sheppard  AFB  on  an  RCA  301.  It  was  a 
closed  shop  operation.  Since  the  RAFT  system  is  no  longer  operational,  current  computer  utili¬ 
zation  figures  do  not  exist.  The  figures  in  the  pie  chart  are  averages  of  utilization  d  uring 
RAFT's  operational  phase. 

Comment:  The  "Other  Time"  could  not  be  broken  down  for  the  only  other  application,  the  Base 
Supply  System. 


RCA  301 


Prod  (RAFT  app) 
126  hrs  17$ 


Other 

604  hrs  83$ 


APPLICATION  PROGRAM  MAINTENANCE:  There  were  three  programmers  involved  with 
program  maintenance.  Their  main  function  was  to  correct  program  errors  and  to  link  the 
various  programs  together  into  a  smooth  operating  system.  The  ratio  of  program  corrections 
to  program  improvements  was  9  to  1.  The  programmers  generally  received  two  test  runs 
per  day  during  RAFT's  operational  phase. 

Comment:  The  maintenance  programmers  also  performed  machine  scheduling,  production 
control,  and  maintenance  of  the  tape  library  of  400  tapes. 
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BENEFITS:  Proposed:  RAFT  was  proposed  as  a  pilot  project  to  verify  the  regional  accounting 
concept.  A  major  air  command  accounting  concept  had  been  rejected  by  Hq.  USAF,  and  RAFT 
was  designed  to  determine  the  feasibility  of  a  centralized  system  over  a  smaller  number  of  bases. 
Benefits  sought  in  RAFT  included  improved  product  design,  elimination  of  unnessary  items  and 
reports,  greater  accuracy,  and  improved  internal  and  external  control. 

Actual:  RAFT  became  operational  at  four  AF  bases  in  June  1964,  thus  verifying  that  a  region¬ 
alized  accounting  and  finance  system  was  feasible.  Because  of  hardware  availability  problems 
and  plans  for  an  Air  Force-wide  standard  accounting  and  finance  system,  RAFT  was  discon¬ 
tinued.  Concepts  developed  in  RAFT  will  be  used  in  development  of  subsequent  accounting 
finance  systems. 


COST  FACTORS: 


Man-Month*  of  Development  Effort  (Dev.) 

Proposed:  Unk  CZZ 

Actual:  381 

Comment:  No  formal  DAP  was  prepared  for  RAFT.  At  a  meeting 
between  Ilq.  USAF  peraonnel  and  ATC  persdnnel,  Air  Force  letter 
177-3  was  drafted  containing  RAFT  concepts  and  schedules. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed  181  1 

Actual:  21 

Comment:  RAFT  system  design  began  on  schedule  on  1  June  1962. 
RAFT  programming  also  began  on  schedule  on  1  July  1962.  Both 
activities  ended  on  schedule.  The  schedule  slippage  was  due  to  a 
delayed  start  of  program  checkout,  caused  by  a  delay  In  the  installa¬ 
tion  of  the  RCA  301  at  Sheppard  AFB,  until  26  June  1963.  Serious 
mechanical  problems  in  the  tape  units  hindered  checkout  from  July 
to  late  October  1963.  when  they  were  overhauled. 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 
Proposed:  Unk  CZ 

Actual:  29.97C 

Comment:  It  was  felt  by  the  developers  that  program  checkout  hours 
would  have  been  less  If, the  equipment  had  been  more  reliable.  Program 
checkout  required  461  hours  on  the  RCA  301  computer. 

Hours/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  UnkC2 

Actual:  126BHBMHHIHH 

Comment:  The  actual  number  represents  the  average  monthly  applica¬ 
tion  production  usage  during  RAFT's  18-month  operational  phase 
(January  1964  to  June  1965)  at  Sheppard  AFB.  RAFT  was  usually  run 
second  shift  after  all  other  work  on  the  Base  Supply  System  had  been 
completed. 


FUTURE  PLANS:  The  region  concept  of  base  level  accounting  and  finance  was  acceptably 
demonstrated  by  conducting  a  comprehensive  test  of  the  RAFT  system.  RAFT  was  deactivated 
in  June  1965  upon  completion  of  this  test.  This  action  was  taken  primarily  because  the  RCA 
301,  which  RAFT  operated  on,  was  replaced  by  the  UNIVAC  1050  II  in  accordance  with  stand¬ 
ardization  of  the  Air  Force's  automated  inventory  control  system  at  a  base  level.  The  major¬ 
ity  of  the  accounting  and  finance  functions  that  were  performed  by  RAFT  have  been  adapted 
to  a  card  system  on  a  Burroughs  B263  at  base  level.  A  new  accounting  and  finance  system  is 
currently  in  development  using  some  of  the  concepts  that  were  developed  and  tested  in  RAFT. 
There  is  some  discussion  that  this  new  system  should  be  usable  either  at  one  base  or  at  sev¬ 
eral  bases  at  a  central  location.  The  workload  analyses  for  this  new  system  were  developed 
by  RAFT  personnel. 


Hours /Month  of  Hardware  Use  for  Program  Maintenance  jQp.) 

Proposed:  Unk  f~~7 

Actual:  Unk  K 

Comment:  Since  RAFT  was  deactivated  in  June  1965,  current  monthly 
uaage  figure*  do  not  exist.  The  program  maintenance  average  monthly 
usage  during  the  18-month  operational  phase  Is  unknown. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  3 

Comment:  The  actual  number  of  personnel  was  prorated  from  four  oper- 
ators  and  one  EDP  officer  on  the  basis  of  time  spent  on  RAFT  during  the 
18-month  operational  phase  at  Sheppard  AFB  ending  in  June  1965. 

Number  of  Program  Maintenance  peraonnel  (Op.) 

Proposed:  Unk  CZ 

Actual  4 

Comment:  The  actual  number  of  peraonnel  wa#  prorated  from  two  analysts 
and  four  programmers  on  the  basis  of  time  devoted  to  RAFT  program 
maintenance  during  the  18-month  operational  phase  at  Sheppard  AFB  ending 
In  June  1965. 

Dollars/Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  CZ 

Actual:  8,775 

Comment:  The  actual  dollar  amount  Is  based  on  regular  shift  changes 
However,  the  RAFT  project  allocated  hardware  costs  on  the  basis  of  extra 
shift  costs  for  those  components  that  were  shared  with  other  applications, 
since  RAFT  used  only  second  and  third  shift  time.  The  cost  of  the  six 
tape  units  used  only  by  RAFT  was  borne  completely  by  RAFT. 
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SYSTEM:  Repair  Requirement  Computation- -RRC  (IBM  7080/1401) 


DATA  SYSTEM  DESIGNATOR:  D07  3 


DATA  COLLECTION  DATE:  July  1966 


LOCATION: 


Contact  for  Additional  Information 

SACS  San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

San  Antonio,  Texas 

Comptroller  (Data  Management  Division) 
Hq.  ,  Air  Force  Logistics  Command 
Wright-Patterson  Air  Force  Base 

Dayton,  Ohio 

Development 

Hq.  ,  Air  Force  Logistics  Command 

Wright* Patterson  Air  Force  Base 

Ohio 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Warner-Robins  Air  Materiel  Area 

Robins  Air  Force  Base 

Georgia 

Maintenance 

Hq.  ,  Air  Force  Logistics  Command 
Wright-Patterson  Air  Force  Base 

Ohio 

Pilot  Installation 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Oklahoma  City  Air  Materiel  Area 

Tinker  Air  Force  Base 

Oklahoma 

First  Operational  Installation 

San  Antonio  Air  Materiel  Area 

Kelly  Air  Force  Base 

Texas 

Number  of  Ope  rational  Installations 

7 

FUNCTION:  The  users  of  RRC  are  the  Directors  of  the  Material  Maintenance  Divisions  of  the 
various  AFLC  Air  Materiel  Areas.  The  mission  of  the  users  is  the  management  of  the  repair 
activity  of  Air  Force  materials.  RRC  functions  as  a  management  support  system  to  identify  the 
items,  quantities,  and  urgency  of  need  of  those  items  to  be  repaired  by  the  Specialized  Repair 
Activity  (3RA).  The  system  functions  on  a  biweekly  frequency  and  produces  a  time  phase  state¬ 
ment  of  repair  requirements  in  order  of  precedence  and  preference,  to  be  accomplished  by 
the  SR  A. 


ORGANIZATION: 


(Developers/ 
Maintalnrr* ) 


(Operator*) 
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HIS  TOR  Y :  Investigations  by  various  government  agencies  in  1964  uncovered  two  major  prob¬ 
lems  in  operations  of  the  Air  Force  Logistics  Command  (AFLC).  First,  an  ineffective  inven¬ 
tory  system  existed,  permitting  one  agency  within  the  command  to  purchase  items  that  were 
being  discarded  simultaneously  by  another  agency  within  the  command.  Second,  an  inadequate 
repair  system  existed,  resulting  in  some  aircraft  being  inoperative  for  many  months  awaiting 
maintenance  for  lack  of  proper  scheduling  of  parts,  manpower,  and  facilities. 

As  a  result  of  these  findings,  the  Commander,  Headquarters  AFLC,  ordered  a  review  of 
the  management  of  recoverable  (repairable)  items.  This  review  concluded  that  AFLC  did  not 
have  the  managerial  tools  to  fulfill  this  function  effectively.  Large-scale  data  processing  sys¬ 
tems  were  being  planned  for  the  distant  future  to  solve  this  problem,  but  it  was  imperative 
that  an  interim  solution  be  developed. 

A  six-man  study  group  was  formed  from  managerial  level  personnel  of  the  Data  Management 
Division  of  Headquarters  AFLC.  This  group  concluded  that  an  automated  system  should  be  de¬ 
veloped  to  permit  the  identification  of  items  and  quantities  needing  repair  and  to  react  in  a 
short-range  time  period  more  closely  aligned  to  the  actual  demand  on  AFLC.  This  group 
formed  the  nucleus  of  a  special  developmental  task  force  that  drew  up  specifications  for  the 
proposed  system  in  March  1965.  The  programming  effort  began  in  April  1965  at  Warner- 
Robbins  Air  Force  Base  as  IBM  7080  computer  time  was  available  there.  The  Management 
of  Items  Subject  to  Repair  (MISTR)  system  resulted  from  this  effort.  The  Repair  Requirement 
Computation  System  (RRC)  is  the  portion  of  the  MISTR  system  that  computes  the  repair  re¬ 
quirements  for  inventory  maintenance. 

System  tests  began  in  May  1965  at  Warner -Robbins  AMA  and  San  Antonio  AMA.  Implemen¬ 
tation  began  at  all  AMA's  in  June  1966.  During  system  implementation,  approximately  70 
major  problems  requiring  changes  to  the  MISTR  system  were  cataloged.  The  task  group  di¬ 
rected  the  extensive  modifications  to  the  system  and  completed  their  task  in  June  1966. 

No  special  management  techniques  were  used  to  control  the  development  of  the  system. 
Progress  reports  on  the  development  status  were  submitted  to  Headquarters  AFLC  on  a 
monthly  basis. 

RRC  is  operational  at  the  following  seven  sites:  Rome  AMA,  Sacramento  AMA,  San 
Bernardino  AMA,  San  Antonio  AMA,  Oklahoma  City  AMA,  Ogden  AMA,  and  Warner  Robbins 
AMA. 


SCHEDULE: 
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DESCRIPTION:  The  Repair  Requirement  Computation  System  identifies  the  items,  quantities 

and  urgency  of  items  to  be  repaired  by  the  Specialized  Repair  Activity  (SRA).  It  operates  on  a 
biweekly  frequency  and  produces  time-phased  statement  of  repair  requirements  in  order  of  prec¬ 
edence  and  preference,  to  be  accomplished  by  the  SRA.  Data  for  computing  the  requirement  is 
extracted  from  the  Inventory  Manager  Stock  Control  and  Distribution  System,  the  System  Support 
Manager  Stock  Control  and  Distribution  System,  and  the  D041  World-Wide  Category  I  and  II  R 
Requirements  Computation  System.  The  resultant  computation  produces  levels  of  Safety,  Re¬ 
pair  Check  Point,  Repair  Projection  Point,  and  Maximum  Repair  Projection.  All  available 
wholesale  assets  and  due-in  quantities  are  then  allocated  to  these  levels.  Deficiencies  in  each 
level  become  repair  requirements  by  precedence.  The  above  computation  is  made  for  each 
family  of  items,  giving  full  consideration  to  the  interchangeability  of  their  parts,  thereby  estab¬ 
lishing  the  preference  for  repair. 


From  Cat.  1  and  HR 
Requirement# 
Computation 
Syatem  (D041) 


From  Syetem  Support 
Manager  Stork  Control 
and  Dietribution  Syetem 
(D034) 


F rom  Inventory 
Management  Stock 
Control  and 
Dietribution 
Syetem  (DO 32) 


From  Worldwide 
Stock  Balance  and 
Coneumption  Report 
Syetem  (DI04) 
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HARDWARE: 


2 -IBM  7080’a 


4-1BM  1401  'a 


1  -IBM  1401 


Com¬ 

puter 

Firat 

Deliv- 

M*o7vr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(a*) 

External 

Storage 

Peripheral  Devicea 

Car. 

Reader /Punch 

Printer 

Internal  Sto 

rage 

No. 

Read 

Speed 

(carda/ 

min) 

Punch 

Speed 

(carda/ 

min) 

No. 

Speed 

(1pm) 

Cycle 

Time 

(U»L 

Char. 

Sise 

(bit.) 

Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapea 

Trana. 

Rate 

2 -IBM 
7080 

9/61 

Char. 

li 

2 

6 

160.000 

20- 
729  VI 

to 

90K 

None 

— 

... 

None 

4-IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8.192 

2- 

729  IV 

22.5K- 
62. 5K 

1- 

1402 

800 

250 

1- 

1403 

600 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8.192 

4- 

729  II 

15K- 
41. 6K 

1- 

1402 

800 

250 

1- 

1403 

600 

Comment:  The  equipment  configuration  varies  with  the  installation  both  between  AMA's 
and  Hq  AFLC.  The  configuration  depicted  above  is  for  the  San  Antonio  AMA. 
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SOFTWARE:  Software  for  both  the  IBM  7080  and  IBM  1401  computers  consisted  of  an  Autocoder 
assembler  and  general  input  and  output  utility  routines.  The  IBM  7080  also  had  a  sort  program 
available. 

COMMENT:  The  software  is  maintained  by  IBM.  Only  canned  programs  are  used  on  the  IBM 
1401  for  RRC. 


APPLICATION  PROGRAM  DEVELOPMENT:  Due  to  the  extreme  importance  of  this  effort,  the 
development  was  assigned  to  a  task  group  under  the  direction  of  the  Data  Management  Division, 
Hq.  AFLC.  Maintenance,  supply,  and  report  management  were  the  three  functional  areas  using 
the  system.  Therefore,  the  task  group  assigned  to  development  organized  itself  along  lines 
responsible  to  these  three  areas.  This  put  the  developers  in  contact  withtheusers  to  facilitate 
design.  The  analysts  were  then  related  directly  to  the  mission  groups.  Personnel  to  staff 
the  development  group  were  brought  in  from  five  AMA's;  also,  one  IBM  programmer  was  used. 
Four  categories  of  people  were  in  the  development  group.  First,  there  were  the  conceptual 
types  who  established  the  system  policies  and  guidelines.  Second,  there  were  procedural 
people  who  specified  operating  instructions.  Third,  there  were  analysts  who  translated  the 
policy  and  procedure  requirements  into  specifications  for  programmers.  Finally,  there  were 
programmers  who  coded  the  system.  No  special  management  techniques  were  used  to  control 
the  development  of  the  system.  Status  reporting  to  Headquarters  was  done  on  a  monthly  basis. 
The  programs  were  written  in  Autocoder  II  to  operate  on  hardware  already  existing  at  all  the 
AMA's.  All  of  the  IBM  1401  software  consisted  of  canned  library  routines.  The  programs  were 
checked  out  individually  at  WRAMA  or  SAAMA  with  the  system  test  following  at  SAAMA  only 
for  4  months.  Program  test  time  was  broken  down  into  223  hours  for  the  IBM  1401  and  135 
hours  for  the  IBM  7080.  System  test  time  is  unknown  since  system  test  was  done  with  live 
data  and  considered  to  be  production  in  some  instances. 


FILE  CONVERSION:  No  file  conversion  was  involved  in  RRC  because  the  system  was  designed 
to  operate  on  existing  files. 
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DOC UMEN TA TION:  The  principle  documentation  for  this  system  is  as  follows:  (1)  AFLCL 
300-11,  App.  1  (a  user's  manual  for  D073  prepared  by  the  repair  agencies;  and  AFLCL  300-11, 
App,  2  (operating  instructions  for  D073),  This  is  a  complete  maintenance  manual  which  in¬ 
cludes  flow  charts  and  format  layouts. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Area 

Of  College 

Development 

Manager 

1 

3 

15 

15 

Unknown 

Analyst 

1 

3 

10 

10 

Unknown 

Programmer 

2 

19 

Unknown 

Unknown 

Unknown 

Operations 

Manager 

4 

0.1 

Unknown 

Unknown 

Unknown 

Operator 

89 

0.4 

2 

Unknown 

XT 

OPERATIONS:  The  computer  operation  is  staffed  at  SAAMA  24  hours  a  day,  7  days  a  week.  It 
operates  as  a  closed  shop.  RRC  is  one  of  many  applications  on  the  IBM  7080's  and  1401's,  A 
daily  schedule  is  followed  by  the  installation  which  is  displayed  on  closed  circuit  TV.  Five  IBM 
1401  computers  are  used  to  process  RRC.  The  pie  chart  below  reflects  utilization  as  if  one  IBM 
1401  did  all  of  the  RRC  application  processing,  and  not  all  five  computers,  which  is  actually  the 
case. 

Comment:  None. 

Off 

98  hr*  I  3% 

Schd  Mt 
43  hr*  6% 

Mach  Error  Lost 
11  hr*  2% 

Unnrhd  Mt 
4  hr*  1% 

Idle 
24  hr*  y% 

Set  Up 
66  hr*  9% 

Chg  Lost  (allother 
•pps)  6  hr*  1% 

Prog  Dev  »  Mt 
(all  other  app*) 

10  3  hr*  14%  IBM  7080  (A) 


Prod  (RRC 
app)  1  5  hr*  2% 
Prog  Dev  *  Mt 
(RRC  app) 

1  hr*  1% 

Prod  (ail  other 
*pp«)  3  36  hr*  46% 


Prog  Dev  6  Mt 
(all  other  app*) 
77  hr*  11% 


APPLICATION  PROGRAM  MAINTENANCE:  Program  maintenance  for  RRC  is  currently  per¬ 
formed  at  Headquarters  AFLC  by  three  personnel  of  the  Data  Management  Division.  There  are 
an  analyst  and  a  programmer  at  each  AMA  to  monitor  the  operation  of  the  system  and  to  in¬ 
stall  program  corrections  received  from  Headquarters  AFLC. 

COMMENT:  None. 


135 


RRC  Sheet  7  of  7 


BENEFITS:  Proposed:  RRC  was  to  assist  AFLC  inventory  management  by  identifying  the  items 
and  quantities  to  be  repaired  in  order  to  maintain  inventory  levels.  An  additional  benefit  from 
RRC  was  to  be  the  production  of  a  biweekly  schedule  of  repair  requirements  to  be  accomplished 
by  Specialized  Repair  Activities.  Repairs  were  to  be  scheduled  in  order  of  precedence  and  pref¬ 
erence  to  improve  control  and  management  of  repairable  carcasses. 

Actual:  RRC  provided  management  tools  to  AFLC  which  had  not  formerly  existed.  It  provided 
scheduling  and  control  of  repair  activities  not  possible  prior  to  RRC  implementation. 


COST  FACTORS: 


Man-Montha  of  Development  Effort  (Dev.) 

Proposed:  Unk  CZ 

Actual:  8  ■■■■■■■■■■ 

Comment-  A  DAP  for  RRC  wu  submitted  to  AFADA  in  March  1965  and 
immediate  verbal  approval  was  given  by  AFADA  for  a  6-month  effort. 
There  was  no  estimate  for  man-months  of  development  effort  stated  In 
the  DAP. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  4  1  "i 

Actual:  4  ■■■■■■■■■■ 

Comment:  The  proposed  Initial  operational  capability  date  was 

TuneTTSV 

Doliars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 
Proposed:  Unk  CZ 

Actual:  62.190 

Comment:  Program  checkout  required  135  hours  on  the  IBM  7080  com- 
puterVnd  233  hours  on  the  IBM  1401  computer. 

Hours/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  20 1  1 

Actual:  4  Mfl 

Comment:  The  actual  number  reflects  usage  during  March  1966  on  the 
IJBM  7060  at  SAAMA.  Fifteen  hours  were  used  for  RRC  application 
production  on  the  peripheral  IBM  1401's.  The  DAP  stated  an  estimate 
of  30  hours/month  per  AMA  for  RRC  application  production  on  the 
IBM  1401  computer. 


FUTURE  PLANS:  A  number  of  modifications  and  minor  corrections  are  being  incorporated  in 
what  is  known  as  a  "block  change.”  A  "block  change"  in  a  system  is  an  extensive  revision  of 
the  programs,  procedures,  and  documentation  reflecting  an  accumulation  of  minor  errors  and 
modifications.  The  modifications  reflect  efforts  to  be  compatible  with  the  "feeder"  systems 
and  changes  of  mission  policies  and  operational  environments.  These  changes  are  scheduled 
to  be  operational  at  all  AMA's  by  September  1966.  This  "block  change"  procedure  is  common 
with  the  Air  Force  Logistics  Command  and  this  system  will  probably  be  modified  in  the  future 
by  this  procedure. 


Houra/Month  of  Hardware  Uae  for  Program  Maintenance  (Op.) 

Propoaed:  Unk  CZ 

Actual:  0  | 

Comment:  The  actual  number  reflecte  uaage  during  March  1966  on  the 
IBM  7080  at  SAAMA.  Program  Maintenance  for  RRC  la  done  only  at 
Hq.  AFLC.  The  operational  AMA'i  have  monitor  programmer/ 
analyata  who  collect  program  error  data  to  aend  to  Hq.  AFLC  and  tnatill 
correctiona  from  Hq.  AFLC.  Seven  houra  were  uaed  for  RRC  program 
maintenance  on  the  peripheral  IBM  140l'a. 

Number  of  Operationa  Peraonnel  (Op.  ) 

Propoaed:  UnkC 

Actual:  1  ■■■■■■■■■■■ 

Comment:  The  actual  number  of  peraonnel  la  prorated  from  89  operator  a 
at  SAAMA  on  the  baala  of  machine  houra  uaed  by  RRC. 

Number  of  Program  Maintenance  Peraonnel  (Op.) 

Propoaed:  Unk  CZ 

Actual:  6  ■■■■■■■■■■ 

Comment:  The  actual  number  of  peraonnel  ia  prorated  from  programmera 
at  SAAMA  and  Hq.  AFLC  on  the  baaia  of  titne  devoted  to  RRC  program 
maintenance. 

Dollara/Month  of  Hardware  Coat  (Op.) 

Propoaed:  Unk  CZ 

Actual:  2.859  ■■■■■■■■■■ 

Comment:  None . 
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SYSTEM:  Appropriation  Accounting  Remote-Random  Access  System- -SC /ACCT 
(IBM  1410) 


DATA  SYSTEM  DESIGNATOR:  H074 


DATA  COLLECTION  DATE:  May  1966 


LOCATION: 


Contact  for  Additional  Information 

Data  Processing  Division 

Directorate  of  Data  Systems 

Air  Force  Systems  Command 

Andrews  Air  Force  Base,  Maryland 

Development 

Air  Force  Systems  Command 

Andrews  Air  Force  Base 

Maryland 

Maintenance 

Air  Force  Systems  Command 

Andrews  Air  Force  Base 

Maryland 

Pilot  Installation 

None 

First  Operational  Installation 

Air  Force  Systems  Command 

Andrews  Air  Force  Base 

Maryland 

Number  of  Operational  Installations 

10 

FUNCTION:  The  users  of  SC/ACCT  are  the  Financial  Divisions  of  the  nine  Air  Force  System 
Command  (AFSC)  Divisions  and  the  Financial  Division  of  AFSC  Headquarters.  The  mission 
of  these  divisions  is  financial  accounting  and  reporting  the  status  of  funds.  SC/ACCT  functions 
as  a  management  support  system  in  financial  and  accounting  operations  by  permitting  direct 
inquiry  and  maintenance  of  a  division's  current  funding  and  listing  periodic  summaries  of  the 
finance  file  contents.  In  addition,  accounting  information  required  by  the  AFSC  Headquarters 
and  by  other  commands  is  provided  by  the  divisions  on  punched  cards  and  magnetic  tape. 


ORGANIZATION: 


(Operator) 
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HISTORY:  From  August  1959  to  January  I960,  a  study  of  the  current  posture  of  the  Air  Force 
Systems  Command's  (AFSC)  data  processing  requirements  was  undertaken.  This  study  re¬ 
sulted  in  the  development  of  a  data  processing  concept  based  on  the  principles  of  standardi¬ 
zation  and  compatibility  of  data  systems  and  equipment.  The  report  was  submitted  in  July 
I960  to  Headquarters  USAF  as  a  program  concept  of  a  total  command  package. 

The  report  included  the  general  identification  of  the  data  systems  to  be  included  in  the  de¬ 
velopment  of  the  program  and  a  detailed  justification  for  the  selection  of  an  IBM  7070/1401 
system  for  Headquarters  AFSC  and  IBM  1410  systems  for  the  divisions.  Accounting  and 
finance  were  among  the  functions  selected  for  standardized  automation  and  were  to  be  part  of 
a  complete  management  system. 

Headquarters  USAF  directed  AFSC  to  make  a  reselection  of  the  data  processing  equipment 
in  accordance  with  a  new  computer  selection  policy.  The  Command  ADP  program  was  rewritten, 
approved  by  Headquarters  USAF,  and  submitted  to  16  manufacturers  as  an  RFP  in  March  1962. 
Two  proposals  were  received  and  the  Headquarters  AFSC  ADP  selection  committee  recom¬ 
mended  the  selection  of  the  IBM  1410  to  Headquarters  USAF  which  approved  the  installation 
of  one  IBM  1410  to  be  installed  at  ESD  as  a  pilot  system.  The  1410  was  installed  at  ESD  in 
August  1963,  and  the  conversion  of  the  accounting  and  finance  system  began  in  September. 
Following  a  Headquarters  USAF  evaluation  of  the  pilot  system,  final  approval  was  granted  in 
February  1964  to  retain  the  ESD  system  and  to  install  eight  additional  1410's  at  the  AFSC 
divisions. 

Early  in  1962,  a  Data  Development  Division  was  established  within  the  Directorate  of  Data 
Systems  at  AFSC  for  the  exclusive  purpose  of  developing  the  command  management  system. 

The  Financial  Management  Branch's  responsibility  was  to  design,  develop,  and  implement  an 
ADP  system  for  accounting  and  finance.  The  Standards  Branch's  responsibility  was  to  define 
software  in  accordance  with  the  system  requirement.  In  addition  to  Air  Force  personnel,  two 
IBM  programmers  provided  programming  support  in  the  Financial  Branch  developing  the  in¬ 
quiry  system  as  well  as  test  programs.  Air  Force  personnel  in  the  Standards  Branch  were 
supplemented  by  four  IBM  programmers  in  the  development  of  the  monitor  system  and  vari¬ 
ous  other  software  packages. 

SC/ACCT  is  operational  at  Hq.  AFSC,  Andrews  AFB,  and  at  nine  AFSC  divisions. 


SCHEDULE: 


138 


SC/ACCT  Sheet  3  of  7 


DESCRIPTION:  The  AFSC  accounting  and  finance  system  provides  a  standard  automated 
accounting  system  for  each  division  within  the  command.  The  system  permits  direct  inquiry  and 
maintenance  of  the  division's  current  financial  funds,  as  well  as  listing  of  periodic  summaries  of 
the  file  contents.  In  addition,  accounting  information  required  by  headquarters  and  by  other  com¬ 
mands  is  provided  on  punched  cards  or  magnetic  tapes. 
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HARDWARE: 


IBM  1410 


Com¬ 

puter 

First 

Deliv- 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal  Storage 

External  Storage 

Peripheral  Devices 

Card  Reader/Punch 

Printer 

Remote 

Consoles 

Mag  Tapes 

Disk 

No. 

Mag 

Tapes 

Trans. 

Rate 

No. 

Disks 

Trans. 

Rate 
(char.  / 
sec) 

Char. 

Ca¬ 

pacity 

Ac  - 

cess 

Time 

(ms) 

No. 

Read 
Speed 
(ca rds  / 
mip) 

Punch 
Speed 
(ca  rds/ 
min) 

No. 

Speed 
0  l*m) 

No. 

Speed 

(cpm) 

Cycle 

Time 

(us) 

Char, 

Size 

(bits) 

Char. 

Ca¬ 

pacity 

IBM 

1410 

11/61 

Char. 

68 

4.5 

6 

40.000 

1  or  2(,) 
7330 

7.2K 

l- 

1301-2 
Model  2 

90.100 

55. 9M 

180 

I  - 
1402 

800 

250 

I- 

1403 

hOO 

2  or  3(2) 
1014 

90 

Comment:  (1)  Six  installations  have  two  7330  tape  transports;  four  installations  have  one  7330 

tape  transport. 

(2)  Three  installations  have  three  1014  remote  consoles,  seven  installations  have 
two  1014  remote  consoles. 
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SOFTWARE:  Software  for  the  IBM  1410  consisted  of  the  following:  (1)  a  monitor  program  de¬ 
signed  for  this  application;  (2)  a  Processor  Operating  System  (POS);  (3)  a  maintainer  pro¬ 
gram  designed  for  this  application;  (4)  a  sort  program;  and  (5)  two  utility  program  packages. 
The  software  was  delivered  by  IBM  with  the  machine  in  August  1963, 

Comment:  The  monitor  program  resides  in  core  storage  at  all  times,  controls  the  use  of 
remotes,  and  establishes  an  interface  between  the  analyzer  program  and  the  application  pro¬ 
grams  stored  on  the  disk.  The  POS  provided  AUTOCODER,  COBOL,  and  FORTRAN  capa¬ 
bilities.  AFSC  also  developed  macros  for  POS  giving  teleprocessing  and  monitor  communica¬ 
tion  capabilities.  The  sort  program  has  been  modified  for  on-line  use  by  the  addition  of  routines 
to  enable  interrupt  processing  and  call  from  another  program.  Both  of  the  utility  program 
packages  were  recompiled  and  relocated  to  convert  from  tape  to  the  disk  system. 


APPLICATION  PROGRAM  DEVELOPMENT:  A  Data  Development  Division  was  established  within 
the  Hq.  AFSC  Directorate  of  Data  Systems  for  the  exclusive  purpose  of  developing  AFSC  man¬ 
agement  systems  for  the  IBM  1410.  The  Financial  Management  Branch's  responsibility  was 
the  system  design,  programming,  testing,  and  documentation  of  the  Appropriation  Accounting 
System,  The  branch  chief  and  his  assistant  supplied  the  input  formats,  the  output  formats, 
the  records  formats,  and  the  logical  approach  for  the  system  design.  The  two  sections  of  the 
Financial  Management  Branch  then  developed  the  detailed  system  design  and  wrote  the  required 
programs  in  AUTOCODER.  The  Standards  Branch  provided  the  software  within  which  the  sys¬ 
tem  was  to  operate,  including  the  monitor  system  and  software  to  simulate  remote  terminals 
which  were  not  available  on  the  test  computer.  The  final  system  test  was  done  on  a  computer 
configuration  with  remote  capabilities.  Approximately  350  hours,  out  of  a  proposed "600  hours 
free  test  time  bid  by  IBM  in  the  proposal,  were  used  for  testing.  The  programmers  were 
allowed  to  see  their  test  run  but  they  could  not  operate  the  computer.  Turnaround  time  was  nor¬ 
mally  24  hours  or  less.  (The  system  test  included  parallel  operations  for  1  month.) 


FILE  CONVERSION:  There  were  three  accounting  and  finance  systems  operating  at  the  bases 
prior  to  the  implementation  of  the  1410  system.  One  was  a  manual  system,  the  second  was  an 
Air  Force  standard  PCAM  system,  and  the  third  was  the  Air  Force  Program  Accounting 
System.  Besides  the  three  different  programs,  there  were  local  codes  used  within  each  of  the 
systems  that  made  even  the  standard  punch  card  system  somewhat  unique  to  each  base.  Those 
bases  with  punch  card  systems  were  directed  by  Headquarters  AFSC  to  develop  conversion  pro¬ 
grams  to  reformat  the  local  card  forms  into  the  new  formats  used  by  the  1410  system,  as  well 
as  to  convert  all  local  codes  into  standard  codes.  These  cards  were  then  entered  into  the  sys¬ 
tem  by  use  of  the  test  simulator  program  to  produce  the  master  files.  The  computer  time  re¬ 
quired  to  make  the  initial  file  development  ran  from  18  hours  to  a  matter  of  days  at  some  bases. 
Those  bases  that  were  on  manual  systems  were  required  to  enter  all  their  transactions  into  the 
system  via  the  remote  keyboard.  This  required  as  much  as  a  week  in  some  instances. 
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DOCUMENTATION:  The  documentation  includes  the  narrative  description  of  the  system,  op¬ 
erator  instructions,  system  flow  charts,  logic  charts,  input  and  output  layouts  and  program 
listings.  This  information  is  contained  in  one  manual,  AFSC  Manual  171-4, 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated 
to  System 

In  ADP 

In  Accounting 

Of  College 

Development 

Manager 

4 

2 

7 

1.5 

0.5 

Analyst  . 

3 

3 

17 

17 

Unknown 

Programmer 

13 

14 

0.5 

0.5 

Unknown 

Operations 

Manager 

None 

U nknown 

Unknown 

Unknown 

Unknown 

Operator 

7 

9 

4 

2 

XT 

OPERATIONS:  The  SC/ACCT  system  is  run  during  regular  business  office  hours.  It  operates 
as  a  closed  shop.  The  SC/ACCT  system  is  one  of  several  applications  on  the  IBM  1410  com¬ 
puter  at  Andrews  AFB. 

Comment:  The  program  development  and  maintenance  is  done  only  at  Headquarters,  AFSC, 
Andrews  AFB.  The  "Other  Time"  could  not  be  defined.  "All  other  application"  program  devel¬ 
opment  and  maintenance  is  included  in  application  production  in  the  pie  chart. 


Other 
135  hrs  18% 

Idle 

189  hrs  26% 


Set  Up 
30  hrs  4% 


SC/ACCT 


Prod  (SC/ACCT 
app)  165  hrs  2  3% 

Prog  Dev  &  Mt 
(SC/ACCT  app) 

28  hrs  4% 

Prod  (all  other 
apps)  17  5  hrs  24% 

Chg  Lost 
(all  apps) 

8  hrs  1% 


APPLICATION  PROGRAM  MAINTENANCE:  Two  programmers  are  currently  involved  in  pro¬ 
gram  improvements  and  corrections  at  Andrews  AFB  where  all  program  maintenance  is 
done.  More  time  is  spent  on  improvement  than  on  correction. 

Comment:  None 
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BENEFITS:  Proposed:  Prior  to  development  of  SC/ACCT,  three  accounting  and  finance  sys¬ 
tems  were  used  at  AFSC  bases.  These  systems  were  either  manual  or  on  PCAM.  The  systems 
also  used  local  codes,  causing  the  systems  to  be  unique  to  each  base.  Benefits  that  were  to  re¬ 
sult  from  implementation  of  SC/ACCT  indluded  a  standard  accounting  and  finance  system  through¬ 
out  AFSC  and  increased  accuracy  and  timeliness  through  the  use  of  state-of-the-art  data  proc¬ 
essing  equipment. 

Actual:  SC/ACCT  was  phased  into  operation  at  different  AFSC  divisions  between  February  1964 
and  July  1965.  The  system  was  standarized  across  all  divisions,  providing  increased  inter¬ 
changeability  of  processing  capability  and  personnel  throughout  AFSC,  in  addition  to  simplifying 
the  production  of  command-wide  reports.  ADP  provided  more  rapid  access  to  accounting  and 
financial  data  than  the  PCAXl  or  manual  systems, 


COST  FACTORS: 


Msn-Months  of  Development  Effort  (Dev.) 

Proposed:  Unit  CZ 

Actual:  226  ■■■■■■■■■■ 

Comment:  No  DAP  was  praparad  for  tha  SC/ACCT  system.  Instead, 
a  study  group  submitted  a  program  concept  to  Hq.  AFSC  (*t  that  time 
Air  Research  and  Development  Commend).  The  study  resulted  la  hard* 
were  recommendations  end  detailed  system  specifications. 


Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  9  i  "  1 

Actual:  12 

Comment:  Once  the  design  was  fixed,  the  system  underwent  little  re* 
design  or  modification,  either  during  or  after  development.  It  was  fait 
by  the  developers  that  the  planned  operational  date  for  the  initial  Installa¬ 
tion  at  Andrews  ATB  was  overly  optimistic. 


Pollers  of  Hardware  Cost  for  Program  Checkout  (Dev.) 
Proposed:  Unk  CZ 

Actual:  26.52S 

Comment:  IBM  bid  600  hours  free  test  time  worth  approximately  $40,900 
for  entire  system  checkout.  Including  system  software.  The  remote  query 
had  to  be  simulated,  since  the  test  computer  had  no  remotes.  This  caused 
no  problems  when  actual  checkout  with  remotes  was  begun.  A  total  of  350 
hours  was  actually  used  for  program  end  system  checkout. 


Hours/Month  of  Hardware  Use  for  Program  Maintenance  (On.) 

Proposed:  Unk  Q 

20 

Comment:  The  actual  number  reflects  usage  on  the  IBM  1410  during 
March  If 66  at  Andrews  ATB. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  UnkCZ 

Actual:  Unk  K 

Comment:  There  are  seven  operators  allocated  to  SC/ACCT  at 

Andrews  ATB.  The  number  of  managers  allocated  to  SC/ACCT  at 
Andrews  ATB  is  unknown. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  2  ■■■■■■■■■ 

Comment:  The  actual  number  represents  full-time  SC/ACCT  maintenance 
programmers  at  Andrews  ATB. 

Dollars /Month  of  Hardware  Cost  (Op.) 

Proposed:  UnkCZ 

Actual:  13,730  ■■■■■■■■■■ 


Hours  /Month  of  Hardware  Use  for  Application  Production  (Op.)  Comment:  None. 

Proposed:  Unk  CZ 

Actual:  163 

Comment:  The  actual  number  reflects  usage  on  the  IBM  1410  duxlnc 
March  l4b6  at  Andrews  AFB. 


FUTURE  PLANS:  Plans  for  changes  or  refinements  to  SC/ACCT  are  indefinite,  with  the  excep- 
tion  of  the  inclusion  of  DOD's  MILCAP  (Military  Contract  Administration  Procedures).  MILCAP 
is  scheduled  for  implementation  by  1  July  1968.  In  addition,  the  advisability  of  adding  civilian 
payroll  to  the  system  and  incorporating  disk  checks  to  improve  disk  reliability  are  under  study. 
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SYSTEM:  SPACETRACK- -SPCTRK  (Philco  2000) 


DATA  SYSTEM  DESIGNATOR:  A005 
DATA  COLLECTION  DATE;  April  1966 


Contact  for  Additional  Information 

Hq.  ,  Air  Defense  Command  (ADOOP) 

Ent  Air  Force  Base 

Colorado  Springs,  Colorado 

Development 

Laurence  G.  Hanscom  Field 

Massachusetts 

Maintenance 

Ent  Air  Force  Base 

Colorado 

Pilot  Installation 

None 

First  Operational  Installation 

Ent  Air  Force  Base 

Colorado 

Number  of  Operational  Installations 

1 

FUNCTION:  The  user  of  SPACETRACK  is  CINCNORAD.  One  of  the  most  important  missions 
of  the  user  is  the  NORAD  space  surveillance  program.  SPACETRACK  functions  as  an  opera¬ 
tional  and  intelligence  support  system  to  detect,  track,  and  maintain  a  central  catalog  of  all 
man-made  objects  in  space  and  provide  ephemerides  on  all  such  objects.  In  addition, 
SPACETRACK  supplies  CINCNORAD  with  information  and  data  for  threat  evaluation  and  de¬ 
cision  making  and  for  the  operation  of  SPADATS.  SPACETRACK  also  has  the  responsibility 
for  backup  to  the  NORAD  (425E)  system  for  processing  BMEWS  display  information. 


ORGANIZATION: 


(OjmtMoi  )  _  _  —  —  —  Information  Flow 
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HISTORY:  In  October  1957  the  first  man-made  orbiting  body,  Sputnik  I,  was  orbited  around  the 
earth  by  the  U.  S.  S.  R.  At  that  time  the  United  States  capability  for  tracking  orbital  elements 
consisted  of  a  private  tracking  system  maintained  by  Dr.  Arthur  Leonard,  an  American  astron¬ 
omer.  In  early  1958,  Leonard  and  two  other  astronomers,  Wahl  and  Frieden,  were  brought  to¬ 
gether  by  the  Advanced  Research  Projects  Agency  (ARPA)  in  a  pilot  project  of  space  tracking. 
Late  that  year,  ARPA  formalized  the  project  by  issuance  of  order  50-59  establishing  a 
"SPACETRACK"  filter  center  at  Bedford,  Massachusetts.  The  order  also  generally  defined 
the  planning  requirements  of  an  operational  system  to  locate,  track,  and  catalog  all  man-made 
objects  in  space.  In  early  1959,  the  Air  Research  and  Development  Command  (ARDC)  was  dele¬ 
egated  the  SPACETRACK  mission  and  established  a  central  data  processing  center  at 
Laurence  G.  Hanscom  Field,  Massachusetts.  The  Air  Force  assumed  responsibility  for  the 
system  in  October  i960  and  the  Air  Defense  Command  (ADC)  was  designated  user.  The  first 
contingent  of  ADC  personnel  began  training  in  the  techniques  and  methods  of  space  detection  at 
Hanscom  Field  in  November  I960.  The  first  or  A  system  became  operational  at  Ent  AFB, 
Colorado,  in  June  1961.  It  was  followed  by  the  A-l,  B-l,  B-2,  and  B-3  systems.  Each  version 
replaced  the  previous  one  (with  only  partial  recoding)  and  increased  the  capability  of  the 
SPACETRACK  system. 

The  earliest  SPACETRACK  development  was  under  the  direction  of  the  Cambridge  Research 
Geophysics  Laboratory  until  early  1961.  The  astrodynamics  and  operational  programs  were 
produced  by  several  universities  and  by  private  industry  under  many  small  contracts. 

The  two  leading  contractors  were  Aeronutronics  and  Wolf  Research  and  Development.  There 
was  no  system  concept  at  this  stage  and  these  early  efforts  were  of  an  R  and  D  nature. 

With  the  transfer  of  responsibility  to  the  Air  Force  in  I960,  Mitre  Corporation  was  given  the 
system  engineering  task  including  overall  technical  responsibility  and  development  of  future 
plans.  During  this  period  personnel  from  the  Computer  Division,  Philco  Corporation,  were 
added  to  the  programming  effort,  while  both  Aeronutronics  and  Wolf  Research  and  Development 
maintained  their  existing  contracts  with  the  Air  Force. 

Continuing  program  additions  and  modifications  have  been  made  since  1961  by  the  above- 
mentioned  contractors,  in-house  Air  Force  personnel,  System  Development  Corporation,  and 
TRW. 

Before  the  B-2  system,  uniform  documentation  did  not  exist  for  SPACETRACK,  although 
system  description  documents  were  produced  as  well  as  a  great  deal  of  program  documentation. 
Since  implementation  of  the  B-2  system,  System  Development  Corporation  has  had  the  respon¬ 
sibility  for  total  documentation  of  the  system  and  its  components.  This  has  resulted  in  stand¬ 
ardized  documentation  consisting  of  several  volumes  which  are  updated  as  the  system  evolves. 


SCHEDULE: 
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DESCRIPTION:  Observations  are  received  via  data  link  from  forward  sites.  If  supplying 
BMEWS  Display  Information  Processor  (DIP)  backup,  the  data  are  transferred  directly  into  the 
computer  by  a  special  input  device  (DMNI),  BMEWS  input  data  are  recorded  for  later 
SPACETRACK  usage.  If  display  output  is  required,  the  messages  are  generated  and  output 
via  a  special  output  device  (DMNO).  For  SPACETRACK  functions,  input  is  usually  prepared 
by  keypunch  machines  that  automatically  convert  punched  paper  tape  to  cards.  The  processed 
observations  are  then  compared  with  predicted  positions  of  the  orbital  elements  in  the  catalog 
and  the  orbital  elements  are  updated.  The  corrected  orbital  elements,  sensor  acquisition 
data  (look  angles),  and  bulletins  are  prepared  for  sensors  and  users. 
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SOFTWARE:  Software  for  the  Philco  2000-212  consisted  of  a  TAC  assembler,  an  ALTAC  com¬ 
piler,  and  an  SYS  operating  system.  The  software  was  delivered  by  Philco  with  the  hardware 
in  October  1  964. 

COMMENT:  The  ALTAC  language  is  a  FORTRAN-like  language  which  includes  the  capability 
to  intermix  the  TAC  assembly  language.  The  ALTAC  compiler  will  accept  either  ALTAC  or 
FORTRAN  input  statements.  The  executive  system  used  by  13-3  was  developed  by  SDC,  using 
segments  of  the  SYS  operating  system.  SPCTRK  and  BMEWS  programs  may  occupy  the  com¬ 
puter  simultaneously  and  be  performing  their  functions  over  the  same  period  of  time  in  the  in- 
terruptable  mode  of  operation.  In  the  noninterruptable  mode,  SPCTRK  occupies  the  computer 
alone. 


APPLICATION  PROGRAM  DEVELOPMENT:  The  first  version  of  SPCTRK  was  programmed  on 
an  IBM  709  in  a  batched  processing  mode  of  operation.  There  was  no  BMEWS  backup  capability. 
The  A  system  stems  from  the  translation  of  programs  from  the  IBM  709  to  the  Philco  2000.  The 
machine  language  programs  were  coded  in  TAC  by  Aeronutronics  Division  of  Ford  Motor  Com¬ 
pany,  and  Wolf  Research  and  Development  Corporation  under  contract  to  Philco  Corporation. 

The  FORTRAN  programs  were  modified  to  comply  with  ALTAC  by  Philco  Corporation,  Com¬ 
puter  Division.  Aeronutronics  was  contracted  to  produce  an  executive  for  the  Philco  2000  which, 
when  coupled  with  the  A  system,  gave  the  A-l  system.  The  B-l  system  included  BMEWS  backup 
capability  and  was  developed  by  the  System  Development  Corporation  (SDC)  to  add  this  capability 
to  the  A-l  system,  which  was  not  reprogrammed.  The  B-2  system,  developed  by  SDC  with  sup¬ 
port  from  Aeronutronics  and  TRW  Systems,  was  a  major  reprogramming  effort.  The  A-l  pro¬ 
grams  were  rewritten  or  modified  along  with  the  BMEWS  backup  modules,  in  order  to  be  tied 
together  under  a  single  monitor.  The  B-2  system  developers  developed  the  B-3  system  in  which 
the  B-2  system  inputs  were  standardized  and  the  file  formats  changed  to  contain  sensor  identi¬ 
fication  information.  The  object  identification  number  was  also  increased  from  three  to  five 
digits.  The  Mitre  Corporation  served  as  system  engineer  and  monitored  the  entire  SPCTRK 
development.  There  are  100  application  programs  in  the  B-3  system,  broken  down  by  origina¬ 
tors  as  follows:  Aeronutronics,  31;  Air  Force  (including  Wolf),  31;  Jet  Propulsion  Laborator¬ 
ies,  3;  Philco  Corporation  (Computer  Division)  16;  SDC,  14;  and  TRW,  5.  The  programs  were 
written  in  the  following  languages:  TAC,  84  programs;  ALTAC,  12  programs;  and  FORTRAN, 

4  programs.  SPCTRK  was  developed  under  375  series  AFR's.  The  system  test  conducted  using 
these  AFR's  was  in  three  phases:  (1)  the  responsible  contractor  ran  programs  individually  and 
as  a  system  monitored  by  the  System  Programming  Office  (SPO);  (2)  the  SPO  ran  the  system; 
and  (3)  operational  personnel  ran  the  system  monitored  by  the  SPO.  Records  of  the  number  of 
checkout  hours  do  not  exist  but  it  is  estimated  that  between  8,000  and  12,000  hours  were  re- 
quired  for  development  of  all  systems  from  A  to  B-3. _ 

FILE  CONVERSION:  The  only  significant  file  conversion  process  in  the  SPACETRACK  system 
took  place  during  the  switch  from  the  B-2  to  the  B-3  system.  This  conversion  was  necessitated 
by  new  formats  for  the  files.  Among  the  changes  were  an  increase  of  the  object  identification 
number  from  3  to  5  digits,  in  order  to  be  able  to  track  over  999  objects,  and  increased  infor¬ 
mation  on  the  sensors  in  the  Observation  (R)  File.  The  files  which  required  conversion  were 
the  Sensor  (S)  file,  the  Observation(R)  File,  and  the  Element  (E)  File.  The  necessary  program¬ 
ming  of  these  conversion  programs  and  the  supervision  of  the  conversion  effort  was  performed 
by  the  Programming  Division  of  the  1st  Aerospace  Control  Squadron.  Three  hours  of  computer 
time  on  the  Philco  2000-212  and  1.5  man-months  of  effort  were  required  to  perform  this  task. 
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DOCUMENTATION:  System  Development  Corporation  has  the  responsibility  for  complete  docu¬ 
mentation.  The  B-3  System  documents  have  been  organized  into  several  series;  e.  g.  ,  Pro¬ 
gram  User’s  Manual  (TM-LX- 193/000/00),  Data  Base  Description  (TM-LX-194/000/00),  Com¬ 
puter  Operator's  Guide  (TM-LX-192/000/00),  etc. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Year* 

Sampled 

Allocated  to 
System 

In  ADP 

In  C  and  C 

Of  College 

Development 

Manager 

None*1* 

Unknown 

8.0 

4.0 

5.0 

Analyet 

NonoO) 

Unknown 

5.0 

4.0 

4.5 

Programmer 

20 

Unknown 

3.0 

2.0 

4.0 

Operation* 

Manager 

9 

9 

3.0 

3.0 

4.0 

Operator 

None(0 

51 

2.0 

2.0 

X 

Note:  (1)  Year*  in  ADP,  C  and  C,  and  college  were  estimated. 


OPERATIONS:  The  computer  operation  is  staffed  24  hours  a  day,  7  days  a  week.  It  operates  as 
an  open  shop.  SPCTRK  is  the  only  application  on  the  two  Philco  2000  computers.  The  Philco 
2000  (A)  computer  is  owned,  while  the  Philco  2000  (B)  computer  is  rented.  A  daily  schedule  is 
strictly  followed  by  the  installation. 

Comment:  The  chargeable  lost  time  for  the  two  computers  was  high,  mainly  because  of  tape  de¬ 
fectiveness  and  maintenance  (44  hours  for  both  computers)  of  the  high-speed  Philco  234-2  tape 
drives.  Programming  and  operator  errors  contributed  another  16  hours  to  chargeable  lost  time 
hours.  Computer  utilization  was  not  obtained  for  the  following:  Philco  1000,  Philco  410,  and 
IBM  1620. 


Other 


Prod  (SPCTRK  only  *pp) 
397  hre  54* 


Other 


62  hre  8* 

Schd  Mt 
54  hre  7* 

Mach  Error  Loet 

2  hre  1* 

Unechd  Mt 

3  hre  1* 

Idle 

149  hre  19* 

Set  Up 
93  hre  13* 


Philco  2000  (B) 


Prod  (SPCTRCK  only  app) 
172  hr*  24*  " 


Prog  Dev  *  Mt 
166  hre  23* 

Chg  Loet 
29  hre  4f 


APPLICATION  PROGRAM  MAINTENANCE:  There  are  currently  17  programmers  involved  with 
program  maintenance.  Six  of  these  programmers  are  civilians  from  Wolf  Research  and 
Development  Corporation.  None  of  these  17  people  were  involved  in  the  original  development 
of  the  system.  It  is  estimated  that  they  spend  85  percent  of  their  maintenance  effort  in  pro¬ 
gram  improvement  and  15  percent  in  program  correction.  They  also  act  as  liaison  to  those 
programmers  at  SDC  doing  major  reprogramming  (Delta  I)  and  will  act  as  integrators  of  the 
resultant  new  system.  The  turnaround  time  for  checkout  never  exceeds  8  hours  and  averages 
5  hours.  Checkout  is  normal  priority  in  this  open  shop  environment.  A  serious  program  prob¬ 
lem,  however,  usually  allows  the  maintenance  programmer  almost  immediate  access  to  the 
computer. 

COMMENT:  None. 
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BENEFIT’S:  The  SPCTRK  effort  was  initially  established  by  the  Advanced  Research  Project 
Car  PA)  in  1958  to  develop  a  system  for  cataloging  space  objects.  Precise  task  requirements 
were  not  levied  but  the  development  effort  was  run  as  an  R&D  program.  SPCTRK  has  evolved 
through  a  series  of  major  modifications  to  provide  the  following  benefits  not  available  to  the  Air 
Force  prior  to  SPCTRK:  (1)  ability  to  detect,  track,  and  maintain  a  central  catalog  of  all  man¬ 
made  objects  in  space  and  provide  ephemerides  on  all  such  objects;  and  (2)  ability  to  collect, 
process,  analyze,  and  display  information  to  CINCNORAD  to  enable  threat  evaluation  and  de¬ 
cision  making.  In  addition  to  the  SPCTRK  benefits,  backup  capability  is  also  provided  to  the 
BMEWS  Display  Information  Processor. 


COST  FACTORS: 


M.in-Months  of  Development  Effort  (l>v.) 


Hours/Month  of  llarJwin-  Use  for  Pr ogrim  Ma in t main  (Op.. I 


Proposal:  Unk  CZ 


Proposrd:  Unk I  / 


Actual  2.424 


Actual:  l«fi 


Comment:  No  formal  DAP  was  prepared  for  SPCTRK.  The  responsibility 
of  SPCYftK  resides  with  the  Air  Defense  Command  (ADC).  The  approarh 
and  tasks  were  modified  several  times  during  development.  Theae  modi¬ 
fications  caused  major  system  design  changes,  and,  hence,  the  develop¬ 
ment  of  several  new  lyatemi,  each  replacing  the  previous  system. 

Months  of  Elapsed  Development  Time  (Dev.) 

Proposed:  Unk  HZ 

-t  mmmmmmmmmm 

Comment:  The  actual  number  ol  months  represents  the  period  from  April 
1061,  when  the  P2000-2II  was  Installed  at  Ent  AFR  and  the  A  system  de¬ 
velopment  was  begun,  to  December  1964,  when  the  B-3  system  was  de¬ 
clared  o)»erational . 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 

Proposed:  UnkQ 

Actual :  Unk  K 

Comment :  Urogram  checkout  records  from  Hansrom  AFR  prior  In  June 
I  'Vl  no  longer  exist.  No  records  were  kept  on  oilier  Pliilcn  2001)  <  urn- 
puters  used  at  Ent  AFB  and  at  Aeronutronics.  These  factors  make  it 
impossible  to  determine  the  computer  hours  required  for  SPCTRK  program 
checkout. 

Ilours/Month  of  Hardware  INe  for  Application  Production  (Op.) 

Proposed:  Unk[~~? 

Actual* 

Comment  The  actual  number  reflects  usage  during  Mari  It  1966  on  both 
14iilro  2(k)<)  (omputers. 


Comment:  The  actual  nmuher  reflects  usage  during  March  |9nb  on  both 
I ’hilco  Z 000  computers. 


Number  ol  Operations  Personnel  (Op.) 
Proposed:  UnkCZ 


Actual : 

Comment : 
military  pi< 

Appro.xim.it 

rmnni'l. 

Number  ol  1 

e|y  2/  1  ol  Ibe  n  tual  miniber  of  personnel  an 

‘rogr.un  M.itiil'*ii.in«  e  Personnel  (Op.) 

Proponed; 

link  CZ 

Ariosi: 

Comment : 

The  a«  liial  i 

•umber  ronsists  ol  13  military  and  7  eivili.tn 

personnel. 

1  foliar 

i  /  M'Hiili  of  Hardware  C.n.l  (tip.) 

1  ‘roposed: 

llnkrz 

Arhial 

Continent; 

None. 

FUTURE  PLANS:  The  SPACETRACK  Facility  is  being  moved  from  Knt  A  KB,  Colorado,  to  fix 
Cheyenne  Mountain  Complex,  Colorado.  During  the  move,  fix*  SPACETRACK  data  is  sent  1o 
Ent  AFB  from  the  new  location  via  two  full-duplex  1 200-bit-per -set  < >n<  1  data  links.  The  B-3 
system  will  be  replaced  by  a  new  system,  Delta  I,  currently  being  developed  by  System 
Development  Corporation  and  the  Aeronutronics  Division  of  Ford  Motor  Company.  Delta  1  is 
basically  the  B-3  system  with  the  following  changes:  (1)  improved  astrodynamic  processes; 
(2)  logic  changes  for  near  real-time  operation  of  sequences  whirl)  .ire  manual  or  semiauto¬ 
matic  in  B-3;  (3)  priority  scheduling  by  executive  control;  and  (4)  new  equipment  which  con¬ 
sists  of  the  real-time  system,  drum  storage,  I/O  data  controller,  on-line*  high  speed  printer, 
on-line  analyst  input  typewriter,  and  an  error  detection  and  alarm  device. 
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SYSTEM:  TAC  Command  and  Control  System--TCC  (IBM  1410) 


DATA  SYSTEM  DESIGNATOR:  A011D 


DATA  COLLECTION  DATE:  May  1966  and  July  1966 


Contact  for  Additional  Information 

Operations  Data  Division 

Directorate  of  Planning  and  Control 
Headquarters,  Tactical  Air  Command 
Langley  Air  Force  Base,  Hampton,  Va. 

Development 

Headquarters,  Tactical  Air  Command 
Langley  Air  Force  Base 

Virginia 

Maintenance 

Headquarters,  Tactical  Air  Command 
Langley  Air  Force  Base 

Virginia 

Pilot  Installation 

None 

First  Operational  Installation 

Headquarters,  Tactical  Air  Command 
Langley  Air  Force  Base 

Virginia 

Number  of  Operational  Installations 

’l 

FUNCTION:  The  user  of  TCC  is  Headquarters,  Tactical  Air  Command.  The  mission  of  the 
user  is  the  management  of  the  Tactical  Air  Command's  resources  in  training,  exercising,  eval¬ 
uating,  refining,  improving,  and  maintaining  a  maximum  combat  readiness  to  meet  any  world¬ 
wide  contingency  requiring  operational  commitments.  TCC  functions  as  an  operations  support 
system  providing  the  Commander  TAC/CINCAFSTRIKE  with  automated  command  and  control 
support  to  assist  in  the  effective  planning,  managing,  and  controlling  of  TAC/CINCAFSTRIKE 
resources  during  normal  and  emergency  situations. 


ORGANIZATION: 


(D«v*lop«r) 
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HISTORY:  In  December  1962,  Headquarters  USAF  approved  a  proposal  by  the  Tactical  Air 
Command  (TAC)  for  an  IBM  1401/1405  system  for  use  in  conjunction  with  the  Headquarters  USAF 
473L  System.  The  equipment  was  installed  and  the  473L  programs  and  data  base  were  loaded  in 
April  1963.  An  abbreviated  Data  Automation  Proposal  was  approved  by  Headquarters  USAF  in 
December  1963  for  contract  programming  to  alter  the  473L  programs  for  greater  responsiveness 
to  the  operational  requirements  of  TAC.  A  request  submitted  by  TAC  was  approved  in  June  1964 
for  an  increase  in  number  of  personnel  to  develop  an  in-house  capability  to  maintain,  update, 
and  develop  programs  in  support  of  the  TAC  Automated  Command  and  Control  System.  An  in¬ 
crease  in  data  processing  capabilities  was  approved  and  the  1401/1405  system  was  replaced  with 
a  1410/1301  system  (operating  in  1401  mode)  which  became  operational  in  November  1965. 

The  developmental  activity  was  contracted  to  IBM  who  has  technical  jurisdiction  over  Air 
Force  personnel  in  this  area.  The  contractor  provides  training  to  the  military  group  in  order  to 
develop  an  in-house  capability.  Mixed  IBM  and  Air  Force  teams  are  responsible  for  system 
analysis  and  program  development.  The  same  team  carries  through  from  system  analysis  to 
programming  and  checkout.  Air  Force  personnel  are  responsible  for  the  operational  usage  of 
the  machine.  Management  control  methods  during  development  included  the  statement  of  work 
and  monthly  progress  reports.  The  monthly  progress  reports  contain  program  status  and  vari¬ 
ances  in  man-months  expended  from  that  budgeted. 


SCHEDULE: 
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DESCRIPTION:  The  broad  functions  of  the  system  are  called  "capabilities";  e.  g.  ,  Force  Status 
Capability,  Airfield  Facilities  Capability.  Each  capability  is  a  series  of  program  modules  used 
to  extract  information  from  the  data  base  and  produce  reports.  In  addition,  there  is  a  semi- 
English  language,  called  the  Query  Language,  which  is  an  alternate  method  for  using  the  capa¬ 
bilities  of  the  system.  Programs  reside  on  the  disk.  A  small  control  program  is  loaded  for 
each  capability,  which  then  automatically  loads  and  reloads  subroutines  to  process  the  request. 
Input  data  are  received  from  TAC  units  and  Hq.  USAF  and  are  used  to  update  the  data  base  peri¬ 
odically.  Query  Language  requests  may  be  used  either  via  the  computer  console  typewriter  or 
via  a  TRW  real-time  console. 


R.ciir.4  vt. 
TTT  and 
AUTODIN 


Command  Po.t 
and  B.ltl.  Staff 
P. r.onn.l 


To  Other 

Command. 
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HARDWARE: 


Com¬ 

puter 

First 
Deliv¬ 
ery 
Mo  /  Y  ? 

Word 

or 

Clia  r . 
Mach. 

Add 

Tim** 

(lIH) 

Internal  Storage 

External  Storage 

Peripheral  Devices 

Card  Reader/Punch 

Printer 

Mag  Tapes 

Disk 

No. 

Mag 

Tapes 

T  rans. 
Rate 

No. 

Disks 

Tr.tns. 

Rat.* 

Char. 
Ca¬ 
pa.  ily 

Ac¬ 

cess 

Time 

(ms) 

No. 

Read 
Speed 
(ca  rds  / 
min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

0pm) 

Cy.  Ic 
Timi' 

( a*  1 

Char. 
Si  *e 
(Wit  n) 

Char. 
Ca  - 
pacity 

I  I'M 

11  MI 

Cha  r. 

KH 

4.5 

6 

40K 

4- 

22.  5K 

1- 

90,100 

55. 9M 

180 

]  _ 

BOO 

250 

I  - 

600 

1410 

729  IV 

62.  5K. 

1301-2 

1402 

140) 

Mofirl  2 

Comment:  Communications  Control  Console  (CCC),  built  by  TRW  is  used  for  real¬ 
time  display  and  interogration.  Hardware  characteristics  for  this 
equipment  are  not  available. 


154 


TCC  Sheet  5  of  7 


SOFTWARE;  Software  supplied  by  IBM  consists  of  the  1401  and  1410  Autocoder  assemblers 
and  the  1400  series  utility  routines  and  software  including  a  general  sort/merge.  Headquarters 
USAF  supplied  the  executive  system  used  by  TCC. 

Comment;  None 


APPLICATION  PROGRAM  DEVELOPMENT;  Two  branches  in  the  Operations  Data  Division  at 
Hq.  TAC  had  the  developmental  responsibilities  for  the  modified  473L  system.  The  System 
Development  Branch  was  mainly  concerned  with  DAP's  and  future  planning,  while  the  Analysis 
^Programming  Branch  aided  IBM  Federal  Systems  personnel  in  system  analysis  and  program 
development.  Because  of  IBM's  experience  and  the  Air  Force's  lack  of  experience  in  this  area, 
IBM  had  technical  jurisdiction  over  Air  Force  personnel.  The  programs  are  divided  into  three 
major  areas;  (1)  control  programs,  which  perform  all  disk  operations;  (2)  utility  programs, 
which  perform  the  repetitive  or  common  system  functions;  and  (3)  capability  programs,  which 
perform  application  functions  such  as  file  generation  and  maintenance,  information  retrieval  and 
display,  and  report  generation.  The  language  used  was  IBM  1401  Autocoder.  When  the  IBM 
1410  was  initially  installed,  the  1401  programs  were  run  in  the  1401  mode  on  the  1410.  The 
executive,  query  language,  and  file  formatting  programs  were  rewritten  for  the  1410  and  1301 
disk  files  by  Hq.  USAF  and  installed  at  TAC.  Because  of  the  magnitude  of  the  system,  the  pro¬ 
grams  were  highly  segmented  and  connective  control  was  provided  by  the  executive  control  pro¬ 
grams.  The  checkout  computer  was  freely  available  during  development  on  an  open  shop  basis. 

A  system  test  was  performed  by  IBM  to  the  satisfaction  of  TAC.  No  records  were  kept  of  de¬ 
velopment  time  used  for  checkout  on  the  computer.  Management  control  was  in  the  form  of  work 
statements  and  monthly  progress  reports. 


FILE  CONVERSION;  File  conversion  affects  two  types  of  data  bases.  The  non-TAC -specific 
files  were  furnished  by  Hq.  USAF,  along  with  the  473L  system.  The  TAC-specific  files  are 
being  converted  on  an  ongoing  basis.  This  means  that  some  functions  are  not  completely  auto¬ 
mated.  The  reason  for  this  is  insufficient  manpower  to  abstract  all  operational  plans  and  other 
data  from  hard  copy  to  punched  cards.  Consequently,  only  the  high-priority  plans  and  data  are 
available  to  the  computer.  The  function  of  file  conversion  rests  with  the  Data  Control  Branch. 
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DOCUMENTATION:  The  documentation  from  the  473L  system  is  used  extensively.  T  AC-specific 
system  and  program  documentation  usually  serves  only  to  augment  an  existing  47 3L  document. 


PERSONNEL: 


Activity 

F  unction 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
Sy  stem 

In  ADP 

In  C  and  C 

Of  College 

Development 

Manager 

6 

6 

5.0 

l.  5 

3.5 

Analyst 

10 

7 

4.5 

1.5 

3.5 

Programmer 

ll 

17 

J.  5 

1.5 

3.0 

Ope  rations 

Manager 

1 

1 

1.5 

1.0 

4.0 

Operator 

7 

1  1 

7.0 

2. 5 

XT 

OPERATIONS:  The  computer  operation  at  Langley  AFB  is  staffed  as  required  by  workload.  It 
operates  during  the  prime  time  as  an  open  shop.  TCC  is  the  only  application  on  the  IBM 
1410  computer.  A  flexible  master  schedule  is  prepared  each  week. 

Comment:  None. 


Off 


Prod  (TCC 

only  app)  220  hrs  30% 


Prog  Dev  &  Mt 
148  hrs  20% 


IBM  1410 


APPLICATION  PROGRAM  MAINTENANCE:  A  total  of  17  programmers  maintain  the  TCC  sys¬ 
tem.  Headquarters  USAF  maintains  the  473L  programs,  but  TAC  makes  and  maintains  its 
own  modifications  and  additions.  Major  corrections  and  improvements  are  handled  by  the  con¬ 
tractor  and  developmental  teams;  minor  maintenance  runs  are  readily  available  with  less  than 
24-hour  turnaround  time.  Changes  are  not  documented  unless  they  affect  the  Operational  Speci¬ 
fications  or  the  Programming/Coding  Specifications. 

Comment:  Program  maintenance  activity  is  characterized  by  the  continual  need  for  improve¬ 
ments  and  additions  to  the  system.  Continuity  is  achieved  by  the  contractor  whose  personnel 
turnover  has  been  low  and  Air  Force  personnel  turnover  has  been  relatively  high. 
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BENEFITS:  Proposed:  TCC  was  proposed  as  an  automated  command  and  control  support 
system  to  provide  the  commander  TAC/CINCAFSTRIKE  with  an  effective  operational  capability 
to  plan,  manage,  and  control  TAC/CINCAFSTRIKE  resources  in  the  execution  of  its  prescribed 
functions,  during  normal  and  emergency  situations  and  in  a  compressed  time/space 
environment. 

Actual:  TCC  was  developed  as  a  major  modification  to  the  existing  Headquarters,  USAF,  473L. 
Command  and  Control  System.  The  system  is  operational  and  providing  the  proposed  benefits; 
additional  development  is  required  to  fully  automate  the  command  and  control  functions. 


COST  FACTORS: 


Man-Montha  of  Davalopmant  Effort  (Pav.) 

Proposed:  UnkCZ 

741  ■■■■■■■■■■ 

Comment:  Tha  phaaa  of  davalopmant  of  tha  TCC  ayatam  dlacuaaad 
Kara  wn  complatad  in  accordanca  with  a  DAP  prapared  on  30  August 
1963  ■pacifically  for  this  davalopmant  affort.  This  DAP  propoaad  to  altar 
tha  47 3Lprog rams,  allowing  tham  to  ba  mora  raaponalva  to  tha  opara- 
tional  raquiramanta  of  TAC.  Hq.  USAF  approvad  tha  DAP  on  9  Dacambar 
1963. 

Montha  of  Elapaad  Davalopmant  Tima  (Dav.) 

Propoaad:  UnkCZ 

Actual: 


Comment:  Tha  actual  davalopmant  pariod  waa  from  May  1964  to  Juna 
1964  It  ancorrpaaaaa  tha  raplacamant  of  tha  IBM  1401/1405  systam 
with  tha  IBM  1410/1301  ayatam  in  accordanca  with  a  DAP  praparad  on 
5  March  1963  and  approvad  by  Hq.  USAF  on  11  Juna  1963. 


Dollars  of  Hardwara  Coat  for  Proiram  Checkout  (Dev.) 
Propoaad:  UnkCZ 


Actual:  UnkK 

Comment:  No  racorda  wara  kapt  of  computar  use  for  tha  47 3L  program 
checkout. 


Hours /Month  of  Hardwara  Uaa  for  Application  Production  (Op.) 

Propoaad:  Unk  CZ 

Actual:  120 

Comment:  Tha  actual  number  reflects  usage  during  March  1966  on  tha 

IBM  TTITJ. 


FUTURE  PLANS:  In  reply  to  a  DAP  dated  26  november  1965,  Headquarters  USAF  proposes 
that  the  IBM  1410  ADP  System  will  be  used  until  December  1968  and  not  be  replaced  between 
July  1967  and  January  1968  as  currently  scheduled  by  DOD.  In  FY  67  an  automatic  communica¬ 
tions  processing  center,  with  an  AUTODIN  terminal  which  will  initially  be  utilized  for  testing 
AUTODIN  capability,  will  be  installed  at  Headquarters  TAC.  I/O  device  testing  is  proposed 
throughout  FY  67  to  determine  feasibility  and  desirability  of  placing  I/O  devices  at  USAF  Head¬ 
quarters  and  selected  Division/ Wing  Command  Posts.  I/O  devices,  if  approved  by  Headquarters 
USAF,  will  be  purchased  and  installed  at  all  TAC  bases  in  FY  69,  making  the  TAC  bases  capable 
of  receiving  information  from  the  Headquarters  TAC  system.  Subsequent  to  the  installation  of 
the  USAF-designated  standard  computer  to  replace  the  interim  IBM  1410,  this  system  will  be 
converted  to  the  new  computer,  probably  during  the  last  half  of  FY  69.  It  is  also  proposed  that 
the  USAF-designated  standard  computer  equipment  and  an  automated  communications  terminal 
be  installed  at  USAF  Headquarters  and  selected  Division/Wing  Command  Posts  in  FY  70. 


Hauaa /Month  of  Hardwara  Dm  for  Proiram  Maintananca  (Op.) 

Propoaad:  Unk  f~7 

Actual:  14S 

Commant:  Tha  actual  numbar  raflacta  uaaga  during  March  1966  on  tha 
IfeM  1410. 

Numbar  of  Oparatlona  Paraonnal  (Op.) 

Propoaad:  Unk  CZ 

Actual:  1 1  ■■■■■■■■■ 

Commant:  Tha  actual  numbar  of  paraonnal  la  for  oparatora  only. 

Numbar  of  Program  Malntananca  Paraonnal  (Op.) 
Propoaad:  Unkr~7 

Actual: 

Commant:  Tha  actual  numbar  of  paraonnal  rapraaanta  programmara 
only.  YKara  ara  alao  7  analyata  and  6  managara  aliocatad  to  TCCV 

Pollara/Month  of  Hardwara  Coat  (Op.) 

Propoaad:  Unk  CZ  * 

Actual:  36.054  ■HHI 

Comma  nt:  Nona. 
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SYSTEM:  Standard  Base  Level  Automated  Inventory  Control  System- -  1 050 /BSS 
(UNIVAC  1050-11) 


DATA  SYSTEM  DESIGNATOR:  D002A 


DATA  COLLECTION  DATE:  May  1966 


Contact  for  Additional  Information 

Headquarters  Command 

Bolling  Air  Force  Base 

Washington,  D.  C. 

Development 

Bolling  Air  Force  Base 

District  of  Columbia 

Maintenance 

Bolling  Air  Force  Base 

District  of  Columbia 

Pilot  Installation 

None 

First  Operational  Installation 

Bolling  Air  Force  Base 

District  of  Columbia 

Number  of  Operational  Installations 

150  planned,  75  currently  in  operation 

FUNCTION:  The  users  of  1050/BSS  are  the  Base  Supply  offices  at  approximately  75  Air  Force' 
bases.  The  mission  of  the  users  is  controlling  the  distribution,  ordering,  and  inventory  level 
for  spare  parts,  equipment,  and  other  supplies  required  by  base  activities.  1050/BSS  func¬ 
tions  as  a  management  support  system  to  establish  a  standard  automated  inventory  control 
system  at  worldwide  Air  Force  bases.  The  functions  performed  by  the  system  include  requisi¬ 
tioning,  receipt,  issue,  stock  control,  turn-in,  disposition,  reporting,  and  accounting.  The 
system  responds  immediately  and  fully  to  all  transactions  as  they  occur  and  provides  standard, 
comparable  reporting  of  data  for  use  by  all  management  levels. 


ORGANIZATION: 


r 


DCS/Sy  atrm* 

and  Logistics 

I 

Directorate  of  Supply  and  Service* 

Supply  Syatema  Design  Office 

ZD 


Voinpf  mile  t 


Directorate  of  Data  Automation 

1 

Directorate  of  Accounting  and  Finance 

Data  Automation  Dealgn  Office 

Data  Syetem*  Control  Office 

Accounting  and  Finance  Dealgn  Offtr* 

(Developer) 


Development 


I 

I 

Group  _ _  _  _ J 


(Developer) 


(Developer) 


Major  Air  Comnundi 

I - 


AF  Baaea 
~~1 - 


Base  Supply  Office 


(Operator/Uaef) 
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HISTORY;  By  1962  each  major  air  command  had  independently  developed  its  own  automated  base 
“  supply  system.  It  was  apparent  that  the  following  problems  existed;  (1)  Headquarters  USAF 
could  not  determine  the  impact  of  supply  policy  changes  throughout  the  Air  Force;  (2)  standard 
supply  management  data  were  lacking;  (3)  personnel  training  was  inefficient;  (4)  multiple- 
development  efforts  were  wasteful.  Supply  procedures  were  standardized  in  an  attempt  to  solve 
these  problems,  but  it  soon  became  apparent  that  equipment  standardization  was  necessary  for 
any  significant  improvement  to  be  realized.  In  July  1962,  a  comprehensive  plan  was  developed 
to  establish  a  standard  ADP  program  for  base  level  material  operations.  The  plan  was 
approved  in  October  1962. 

Systems  specifications  were  developed  by  the  Directorate  of  Supply  and  Services,  Head 
quarters  USAF  assisted  by  personnel  from  Headquarters,  Air  Force  Logistics  Command 
(AFLC).  In  February  1963  the  specifications  were  released  to  industry.  Proposals  were  re¬ 
ceived  and,  in  November  1963,  the  Air  Force  announced  that  Sperry-Rand  Corporation  had  been 
selected  to  provide  approximately  150  base-level  supply  activities  with  a  standard  configuration 
of  data  processing  equipment. 

System  design  of  the  Standard  Air  Force  Base  Level  Supply  ADP  System,  which  would  be 
implemented  Air  Force-wide  by  March  1966,  began  in  December  1963  at  Andrews  AFB. 

A  Central  Development  Group  under  Headquarters  USAF  was  formed  with  the  responsibility 
for  program  development,  implementation,  and  maintenance.  The  group  was  comprised  of  a  body  of 
supply  personnel  under  the  direct  control  of  the  Director  of  Supply  and  Services,  Headquarters, 
USAF,  and  of  programmers  under  the  Director  of  Data  Automation.  After  the  programs  were 
written  and  tested,  they  were  implemented  at  Andrews  AFB.  Simultaneously  with  the  latter 
phases  of  writing,  testing,  and  implementing  at  Andrews,  training  of  Major  Air  Command 
personnel  began.  After  a  trial  operational  phase,  the  programs  were  evaluated  and  necessary 
changes  and  improvements  were  made.  With  the  completion  of  the  changes  and  improvements, 
the  other  bases  became  operational  at  the  rate  of  10  installations  per  month. 


SCHEDULE; 
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DESCRIPTION:  The  1050/BSS  computer  system  is  controlled  by  an  executive  routine  which  is 
always  in  memory.  This  routine  examines  the  input  request,  either  supply  or  accounting/ 
finance,  and  calls  the  required  processing  programs  and  data  from  the  disk.  The  programs 
are  operated,  the  data  file  is  accessed  and  modified  if  necessary,  a  history  of  the  processing 
is  recorded  on  magnetic  tape,  and  the  output  response  is  sent.  The  inputs  and  outputs,  except 
for  the  printer,  are  buffered  and  controlled  by  interrupts.  In  addition  to  normal  processing, 
the  system  produces  management  reports  and  performs  the  accounting  and  finance  functions 
associated  with  the  supply  system. 


Transactions  arc  Received  Via 
Radio,  TTY,  Hand  Carrying  or 
Direct  Remote  Console  Input 
From  Supply  Offices 


Counters,  etc. 
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HARDWARE: 


Unlvac  1050  (Configuration  "B") 


Com¬ 

puter 

Flret 

Deliv- 

MoVvr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(ua) 

Internal  Storage 

External  Storage 

Peripheral  Device 

Card  Reader/Punch 

e 

Printer 

Mag  Tapee 

Drum 

No. 

Mag 

Tapee 

Trane. 

Rate 

No. 

Drume 

Trane. 

Rate 

(char./ 

eec) 

Char. 

Ca¬ 

pacity 

Ac- 

ceee 

Time 

(me) 

No.' 

Read 

Speed 

(carde/ 

min) 

No. 

Punch 

Speed 

(carde 

min) 

No. 

Speed 

0pm) 

Cycle 

Time 

(ue) 

Char. 

Sice 

(bite) 

Char. 

Ca¬ 

pacity 

Uni  vac 
1050 

9/63 

Char. 

117 

4.5 

6 

20.480*1* 

1- 

1071 

23K 

1- 

1057-4 

156 

66MU) 

35 

1- 

1051 

400 

1- 

1052 

300 

1  - 
1053. 

900 

Comment!:  (1)  C  configuration  systems  have  24,516  core  storage. 

(2)  A  configuration  systems  have  33M  character  drum  storage. 

(3)  Three  different  configurations  are  used  depending  on  workload  at  the  installation: 

A  configuration  has  33M  character  drum  storage,  20,480  core  storage. 

B  configuration  has  66M  character  drum  storage,  20,480  core  storage. 

C  configuration  has  6M  character  drum  storage,  24,576  core  storage. 
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SOFTWAP  E :  Software  for  the  UNIVAC  1050  consisted  of  the  following:  (1)  PAL  card  and  tape 
assembly  language  systems;  (2)  input  and  output  utility  programs;  (3)  library  maintenance 
and  sort  programs;  (4)  FASTRAND  tape  utility  programs;  and  (5)  an  executive  control  system. 
Portion  of  the  software  were  delivered  by  UNIVAC  at  different  times  between  February  and 
July,  1964. 

Comment:  The  executive  system  did  not  have  adequate  restart/backup/recovery  capability 
nor  did  It  provide'  automatic  response  to  remotes.  Considerable  reprogramming  of  the  ex¬ 
ecutive  system  was  required  to  provide  these  capabilities.  The  resultant  system  had  many 
bugs  and  this  hindered  development  considerably.  The  executive  system  was  not  considered 
acceptable  until  approximal ely  one  year  after  delivery.  No  major  problems  were  experienced 
with  any  of  the  other  software  packages. 


APPLICATION  PROGRAM  DEVELOPMENT:  A  Central  Development  Group  was  established  by 
the  Air  Stall  to  operate  under  Hq._USAF  aF Bolling  AFB.  This  group  was  responsible  for  pro¬ 
gram  development,  implementation  and  maintenance.  The  group  was  comprised  of  a  permanent 
body  of  supply  personnel  under  the  direct  control  of  the  Directorate  of  Supply  and  Services,  Hq. 
USAF,  and  of  computer  programmers  under  the  Directorate  of  Data  Automation.  A  short  time 
later,  it  was  decided  to  incorporate  Accounting  and  Finance  functions  into  the  system,  leading 
to  the  inclusion  of  permanent  members  to  the  group  from  the  Directorate  of  Accounting  and 
Finance.  In  view  of  the  magnitude  of  the  system,  it  was  further  decided  to  augment  the  group 
with  vendor  personnel  and  representatives  from  the  Major  Air  Commands.  A  project  manager 
was  selected  from  the  Directorate  of  Data  Automation  to  direct  the  development  and  implementa¬ 
tion  at  the  first  10  bases.  This  project  manager  was  scheduled  to  be  replaced  after  the  tenth 
base's  implementation  by  a  man  from  the  Directorate  of  Supply  and  Services,  but  this  has  not 
occurred  yet  due  to  the  many  changes  and  corrections  currently  going  on. 

A  test  computer  was  available  at  Bolling  AFB  on  a  continuous  24-hour-a-day  basis  ex¬ 
clusively  for  this  system's  checkout.  Each  programmer  was  required  to  run  his  own  tests  for 
a  period  of  six  months  in  order  to  become  sufficiently  familiar  with  the  computer  operation  to 
ensure  successful  field  implementation.  This  policy  resulted  in  console  debugging  which, 
coupled  with  the  fact  that  no  programmers  had  any  UNIVAC  1050-11  or  disk  file  storage  experi¬ 
ence,  led  to  extensive  computer  checkout  time.  There  were  no  formal  test  procedures.  Test 
decks  were  prepared  to  test  the  programs,  which  were  all  written  in  PAL  assembly  language. 

A  team  from  the  Central  Programming  Group  at  Bolling  AFB  was  sent  to  the  first  base  to  be 
converted  within  each  Command  to  aid  in  conversion.  After  receiving  this  support  for  the  first 
base,  the  Command  was  responsible  for  aiding  the  remaining  bases. 


FILE  CONVERSION:  There  were  16  different  base  level  supply  inventory  systems  in  the 
Air  Force  prior  to  the  UNTVAC  1050-11  implementation.  These  included  card  systems  (PCAM), 
three  different  RAMAC  305  systems,  a  1401  card  system,  a  1401  tape  system,  GE  225, 
Burroughs  220,  etc.  All  these  systems,  however,  did  have  a  common  element  in  the  punched 
card.  The  conversion  process  consisted  of  a  download  (preparation  of  a  complete  file  of 
punched  cards)  and  an  upload  (reading  the  punched  cards  into  the  1050).  There  were  over 
160  different  types  of  inputs  which  could  be  entered  into  tm;  systems,  which  presented  sufficient 
complexity  to  require  40  conversion  programs  to  be  written.  UNIVAC  was  responsible  for 
writing  the  majority  of  these  conversion  programs  with  the  aid  of  three  Air  Force  programmers 
(UNIVAC  provided  seven  or  eight).  A  team  from  the  central  programming  group  at  Bolling  was 
sent  to  the  first  base  to  be  converted  within  each  Command  to  aid  in  conversion.  The  Command 
was  responsible  for  aiding  the  remaining  bases. 


/ 
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DOCUMENTATION:  The  system  is  well  documented  in  Air  Force  Manuals  77-206,  and  67-1. 


PERSONNEL: 


Activity 

Function 

Number  of  People 

Number  of  Years 

Sampled 

Allocated  to 
System 

In  ADP 

In  Supply 

Of  College 

Development 

Manager 

18 

27 

2.5 

15.0 

Unknown 

Analyst 

35 

40 

0.5 

4.0 

Unknown 

Programmer 

23 

36 

2.0 

4.0 

U  nknown 

Operations 

Manager 

None 

U nknown 

U  nknown 

Unknown 

Unknown 

Operator 

None 

7.7 

U  nknown 

Unknown 

OPERATIONS:  All  operational  sites  operate  independently.  The  pie  chart  represents  usage  on 
a  "iJ"  computer  configuration  at  Andrews  AFB.  All  operational  sites  operate  as  closed  shops, 
and  are  staffed  as  required  by  workload. 

Comment:  None. 


Other 
122  hr s  16# 

Off 

65  hr s  9# 

Schd  Mt 
15  hr  s  2# 
Idle 
12  hr  s  2# 

Chg  Lost 
12  hrs  2  # 


Prod  (BSS  only  app) 
504  hrs  69# 


UNIVAC  1050-U 


APPLICATION  PROGRAM  MAINTENANCE:  The  program  maintenance  activity  is  carried  on  by 
68  programmers  in  the  Central  Programming  Group  at  Bolling  AFB.  There  are  no  maintenance 
programmers  at  the  operational  bases.  The  operators,  having  attended  a  two-week  program¬ 
ming  course,  locate  problem  areas  when  possible,  and  send  details  to  Bolling.  The  operators 
are  not  allowed  to  change  any  program  unless  specifically  directed  by  the  Central  Programming 
Group.  Currently,  it  is  estimated  that  80  to  90  percent  of  the  program  maintenance  activity 
is  correction  of  existing  programs  with  the  remaining  time  spent  on  new  programs. 

Comment:  None. 
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BENEFITS:  Proposed:  Benefits  proposed  to  come  from  development  and  implementation  of 
1 050/BSS  include  (1)  standardization  of  automated  inventory  control  systems  at  approved  bases, 
(2)  reduced  need  for  system  analysis  and  design  through  minimizing  the  number  of  authorized 
inventory  control  automation  efforts;  (3)  greater  discipline  in  enforcing  supply  policy;  (4)  de¬ 
velopment  of  standard  training  courses  enabling  supply  personnel  to  be  used  immediately  in 
any  command;  and  (5)  generation  of  standard  comparable  management  data  for  use  at  all  man¬ 
agement  levels. 

Actual:  The  proposed  benefits  have  been  realized  with  the  implementation  of  1050/BSS.  In  the 
course  of  development,  a  number  of  additional  features  such  as  accounting  for  materiel  re¬ 
sources  were  added  to  the  system. 


COST  FACTORS: 


Man-Months  of  Development  Effort  (Dev.) 

Proposed:  300  |  1 

Actual:  1 ,400  ■■■■■■■■■■■ 

Comment:  No  DAP  was  prepared  tor  the  Base  Level  Supply  System.  In¬ 
st  eaJ]  fn  July  1962,  »  comprehensive  plan  was  developed  within  the  Mate¬ 
rial  Automation  Branch  of  Hq.  USAF  for  the  establishment  of  a  standard 
ADI'  program  for  supply  systems.  This  plan  was  approved  byHq.  USAF 
and  further  development  led  to  the  purchase  of  the  UNIVAC  1050  U  com¬ 
puter  (or  approximately  150  base  level  supply  systems. 

Mon tiis  of  Elapsed  Development  Time  (Dev.) 

Proposed  10  1  I 

18 

Comment  The  *ystrm  development  began  In  November  1963  and  ended 
in  April  Pl65. 

Dollars  of  Hardware  Cost  for  Program  Checkout  (Dev.) 

Proposed:  Unk  Q 

Actual:  Unk  W 

Comment:  The  checkout  computer  wan  available  on  a  continuous  24-hour 
a-day  f>a  sis.  The  number  of  hours  used  for  program  checkout  was  not 
available. 

ilours/Month  of  Hardware  Use  for  Application  Production  (Op.) 

Proposed:  Unk  CZ 

Actual:  504 

Comment:  The  actual  number  reflects  usage  during  a  recent  representative 
month  on  the  "B"  configuration  of  the  UNIVAC  1050  II  at  Andrews  AFB. 


Hours /Month  of  Hardware  U»t  for  Program  Maintenance  (Op.) 

Proposed:  Unk  CZ 

Actual:  Unk  K 

Comment:  AH  program  maintenance  la  dnne  at  Bolling  AFB  on  a  ‘•C’* 
configu  ration. 

Number  of  Operations  Personnel  (Op.) 

Proposed:  Unk  CZ 

Actual:  7.1 

Comment:  The  .o  tual  number  of  personnel  is  prorated  from  operators  at 
Andrews- A FB  on  the  basis  of  machine  hours  for  1050/BSS. 

Number  of  Program  Maintenance  Personnel  (Op.) 

Proposed:  link  CZ 

Actual-  h« 

Comment:  The  actual  number  of  personnel  consists  of  34  analysts  and 
t r  programmers  at  Bolling  AFB.  All  program  maintenance  Is  Hone  by  the 
Central  Programming  Group  at  Bolling  AFB.  There  are  no  maintenance 
programmers  at  the  other  base*.  The  operators  have  been  trained  lo  In¬ 
sert  program  rorrcilion.  from  Bolling  AFB. 

Dollars /Month  of  Hardware  Cost  (Op.) 

Proposed:  Unk  f~7 

Actual:  2,*iVH 

Comment:  1  he  actual  dollar  amount  reflects  the  "  B  '  configuration  ai 
Andrew*  AFB  lor  production  only. 


FUTURE  PLANS:  The 
150  bases  projected, 
month.  The  expected 
of  the  implementation 


system  is  currently  operational  at  about  half  of  the  approximately 
The  implementation  is  expected  to  continue  at  about  10  bases  per 
system  lifetime  is  six  years.  Future  plans  other  than  the  completion 
schedule  are  unknown  at  present. 
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IV.  GLOSSARY 


This  glossary  consists  of  two  primary  sections.  The  first  section 
is  a  general  glossary  of  Air  Force  and  data  processing  terms.  This  sec 
tion  is  based  on  the  Bureau  of  the  Budget  (BOB)  Glossary  of  Automatic 
Data  Processing.  Definitions  have  been  freely  modified  to  reflect  the 
specific  meaning  of  terms  used  throughout  this  project.  A  number  of 
terms  not  defined  in  the  BOB  glossary  are  included  here. 

The  second  section  is  a  glossary  of  cost  factors  and  workload  de¬ 
scriptors.  Cost  factors  appear  in  the  Cost  Factors  section  of  system 
descriptions  and  in  the  cost  estimation  iso-graphs,  while  workload  de 
scriptors  appear  in  the  Workload  section  of  the  system  descriptions  and 
in  the  cost  estimation  iso-graphs. 

A.  Glossary  of  Air  Force  and  Data  Processing  Terms 
ADC  Air  Defense  Command 


ADP 

Automatic  data  processing;  data  processing 
performed  by  a  system  of  electronic  or  elec¬ 
trical  machines  so  interconnected  and  inter¬ 
acting  as  to  reduce  to  a  minimum  the  need 
for  human  assistance  or  intervention. 

ADPS 

Automatic  data  processing  system.  (See  "Sys¬ 
tem,  Automatic  Data  Processing.") 

AF 

Air  Force 

AFADA 

Air  Force  Director  of  Data  Automation 

AFAFC 

Air  Force  Accounting  and  Finance  Center 

AFLC 

Air  Force  Logistics  Command 

AFM 

Air  Force  Manual 

AFO 

Accounting  and  Finance  Office 

AFR 

Air  Force  Regulation 

AFSC 

Air  Force  Systems  Command  (formerly  ARDC) 

ALGOL 

Algorithmic  Oriented  Language;  an  international 
procedure- oriented  language. 
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Algorithm 

A  prescribed  set  of  well-defined  rules,  or  a 
process,  for  the  solution  of  a  problem  in  a 
finite  number  of  steps;  e.g.,  a  full  statement 
of  an  arithmetical  procedure  for  evaluating 
sin  X  to  a  stated  precision. 

AMA 

Air  Materiel  Area 

Analyst,  System 

(See  "System  Analyst.") 

Application 

The  system  or  problem  to  which  a  computer  is 
applied. 

Application 

Preparation 

Any  computer  processing,  such  as  file  conver¬ 
sion,  required  to  allow  an  application  to  be  run. 

Application 

Production 

Any  computer  processing  resulting  in  the  gen¬ 
eration  of  output  to  the  application  user(s). 

ARDC 

Air  Research  and  Development  Command 
(currently  AFSC) 

ASD 

Aeronautical  Systems  Division  of  AFSC 

Assemble 

To  prepare  a  machine  language  program  from 
a  symbolic  language  program  by  substituting 
absolute  operation  codes  and  addresses  for 
symbolic  operation  codes  and  addresses  on  a 
one-for-one  basis.  Normally  performed  by  a 
computer  program  called  an  assembler. 

Assembly 

Language 

The  machine- oriented  programming  language 
(e.g.,  FAP,  EASY)  belonging  to  an  assembly 
system. 

ATC 

Air  Training  Command 

AUTODIN 

Automatic  Digital  Information  Network;  a 
computer-based  communication  network  pri¬ 
marily  used  by  the  Air  Force,  but  also  used  by 
other  agencies  of  the  Federal  Government. 

Capacity,  Storage 

The  amount  of  data  that  can  be  contained  in  a 
storage  device. 

Card,  Master 

A  card  containing  fixed  or  indicative  information 
for  a  group  of  cards.  It  is  usually  the  first  card 
of  that  group. 
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CBPO 

Consolidated  Base  Personnel  Office;  Air  Force 
organizational  element  responsible  for  base- 
level  personnel  functions. 

Channel 

(1)  A  path  along  which  signals  can  be  sent  (e.g., 
data  channel,  output  channel);  (2)  the  portion  of 
a  storage  medium  that  is  accessible  to  a  given 
reading  station  (e.g.,  track,  band). 

Character 

One  symbol  of  a  set  of  elementary  symbols,  such 
as  those  corresponding  to  the  keys  on  a  typewriter. 
The  symbols  usually  include  the  decimal  digits  0 
through  9,  the  letters  A  through  Z,  punctuation 
marks,  operation  symbols,  and  any  other  single 
symbols  a  computer  may  read,  store,  or  write. 

A  character  will  normally  be  represented  by  a 
combination  of  six  bits. 

Chart,  Flow 

A  graphic  representation  of  the  major  steps  of 
work  in  process.  The  illustrative  symbols  may 
represent  documents,  machines,  or  actions 
taken  during  the  process.  The  area  of  concen¬ 
tration  is  where  or  who  does  what  rather  than 
how  it  is  to  be  done. 

Chart, 

Logical  Flow 

A  detailed  solution  of  the  work  order  in  terms 
of  the  logic,  or  built-in  operations  and  charac¬ 
teristics,  of  a  specific  machine.  Concise  sym¬ 
bolic  notation  is  used  to  represent  the  informa¬ 
tion  and  describe  the  input,  output,  arithmetic, 
and  logical  operations  involved.  The  chart 
indicates  types  of  operations  by  use  of  a  stand¬ 
ard  set  of  block  symbols.  A  coding  process 
normally  follows  the  logical  flow  chart. 

Chart, 

Systems  Flow 

A  schematic  representation  of  the  flow  of  infor¬ 
mation  through  the  components  of  a  processing 
system. 

Checkout 

(1)  A  general  term  for  a  set  of  routines  designed 
to  provide  the  programmer  with  a  complete  eval¬ 
uation  of  his  program  under  operating  conditions; 

(2)  the  process  of  checking  out  a  program  to  en¬ 
sure  successful  operation  under  all  conceivable 
conditions. 

Closed  Shop 

(See  "Shop,  Closed.") 

COBOL 

Common  Business  Oriented  Language;  a  busi¬ 
ness  data  processing  language. 
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Compile 

To  prepare  a  machine  language  program  from  a 
computer  program  written  in  another  program¬ 
ming  language  by  performing  the  usual  functions 
of  an  assembler  and  also  by  making  use  of  the 
overall  logical  structure  of  the  program  or  gen¬ 
erating  more  than  one  machine  instruction  for 
each  symbolic  statement  or  both. 

Compute 

A  computer  processing  function  that  performs 
logical,  arithmetic,  and  decisional  operations 
on  data. 

Computer-  Limited 

Pertaining  to  a  situation  in  which  the  time  re¬ 
quired  for  computation  exceeds  the  time  required 
to  read  inputs  and  write  outputs. 

Configuration 

A  group  of  machines  that  are  interconnected 
and  programmed  to  operate  as  an  interacting 
assemblage. 

Control 

A  computer  processing  function  that  expedites 
all  other  computer  processing  functions;  e.g., 
job  scheduling,  priority  handling,  segment 
overlaying,  data  management,  and  hardware 
assignment. 

Conversion 

(1)  The  process  of  changing  information  from 
one  form  of  representation  to  another,  such  as 
from  the  language  of  one  type  of  machine  to  that 
of  another  or  from  magnetic  tape  to  the  printed 
page.  (2)  The  process  of  changing  from  one 
data  processing  method  to  another  or  from 
one  type  of  equipment  to  another;  e.g.  , 
conversion  from  punch  card  equipment  to 
magnetic  tape  equipment. 

CPU 

Central  Processing  Unit;  that  part  of  a  com¬ 
puter  system  containing  the  arithmetic  unit, 
execution  control,  and  special  register  groups. 

DAP 

Data  Automation  Proposal;  a  document  that 
must  be  prepared  and  submitted  to  AFADA  for 
any  proposed  new  data  automation  or  major 
change  to  an  existing  automated  system. 

Data 

A  general  term  used  to  denote  any  or  all  facts, 
numbers,  letters,  and  symbols,  or  facts  that 
refer  to  or  describe  an  object,  idea,  condition, 
situation,  or  other  factors.  It  connotes  basic 
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elements  of  information  that  can  be  processed 
or  produced  by  a  computer. 


Data,  Test 

A  set  of  data  developed  specifically  to  test  the 
adequacy  of  a  computer  program  or  system.  The 
data  may  be  actual  data  that  have  been  taken  from 
previous  operations  or  artificial  data  created  for 
this  purpose. 

Data,  Transaction 

A  set  of  data  in  a  data  processing  area,  a  rec¬ 
ord  of  occurrence  of  a  new  event  or  transaction, 
in  which  the  incidence  of  the  data  is  essentially 
random  and  unpredictable.  Hours  worked,  quan¬ 
tities  shipped,  and  amounts  invoiced  are  ex¬ 
amples  from  the  areas  of  payroll,  accounts  re¬ 
ceivable,  and  accounts  payable,  respectively. 

Data  Base 

A  collection  of  files  containing  unique  informa¬ 
tion;  these  files  are  accessible  to  an  ADPS. 

The  files  of  a  data  base  are  normally  referenced 
or  updated  with  relatively  high  frequency.  Reor¬ 
dered  files  are  not  included  in  the  data  base. 

Data  Base 

Growth  Rate 

The  amount  by  which  the  size  of  the  data  base 
will  increase  over  a  specified  period  of  time, 
normally  measured  in  percentage  of  data  base 
current  size  per  month. 

Date,  Delivery 

The  date  of  physical  delivery  on  site  of  the 
components  of  the  computer  configuration  with¬ 
out  regard  to  whether  or  not  they  have  been  un¬ 
packed,  placed  in  final  position,  or  intercon¬ 
nected.  Delivery  of  equipment  carries  no 
connotation  of  operational  status. 

Date,  Installation 

The  date  new  equipment  is  ready  for  use.  The 
commencement  of  rental  normally  begins  on 
the  day  following  the  date  on  which  the  con¬ 
tractor  officially  notifies  the  using  organiza¬ 
tion  that  the  equipment  is  installed  and  ready 
for  use,  subject  to  the  acceptance  and  standard 
of  performance  provisions  of  the  applicable 
contract. 

Debug 

To  isolate  and  remove  the  mistakes  from  a  rou¬ 
tine  in  a  program  or  malfunction  from  a  computer 

Design,  Functioned 

The  specification  of  the  working  relations  be¬ 
tween  the  parts  of  a  system  in  terms  of  their 
characteristic  actions. 
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Development  Phase 

The  period  of  time  from  the  date  system  design 
for  the  ADPS  is  begun  to  the  date  the  system  is 
declared  operational.  During  this  phase,  such 
activities  as  detailed  system  design,  program¬ 
ming,  checkout,  and  equipment  installation  are 
accomplished  as  required. 

Device,  Input 

A  machine  that  translates  data  to  be  processed 
from  coded  representations;  e.g.,  punch  cards 
or  paper  tape  to  electric  impulses  for  use  by  a 
computer . 

Device,  Output 

A  machine  that  translates  the  electrical  impulses 
representing  data  processed  by  the  computer  into 
permanent  results,  such  as  printed  forms,  punched 
cards,  and  magnetic  writing  on  tape. 

Device,  Storage 

A  machine  into  which  data  can  be  inserted,  in 
which  data  can  be  retained,  and  from  which  data 
can  be  retrieved. 

Documentation 

The  group  of  techniques  necessary  for  the  orderly 
presentation,  organization,  and  communication  of 
recorded  specialized  knowledge  in  order  to  main¬ 
tain  a  complete  record  of  reasons  for  changes  in 
variables.  Documentation  is  necessary  not  so 
much  to  give  maximum  utility  as  to  give  an  un¬ 
questionable  historical  reference  record. 

DOD 

Department  of  Defense 

DSAP 

Data  System  Automation  Program;  the  official 
data  automation  program  of  USAF.  It  provides 
a  coordinated  and  common  basis  for  planning, 
designing,  and  operation  of  USAF  ADP  systems. 
Each  major  data  automation  is  assigned  a  four- 
or  five-character  DSAP  designator.  The  first 
character  of  the  designator  is  alphabetic  and 
indicates  the  major  functional  area  of  the 
automation. 

El  ernont,  Data 

A  specific  item  of  information  appearing  in  a 
set  of  data.  For  example,  in  the  following  set 
of  data,  each  item  is  a  data  element:  the  quan¬ 
tity  of  a  supply  item  issued,  a  unit  rate,  an 
amount,  and  the  balance  of  stock  items  on  hand. 

Element  Error 

Rate 

The  ratio  of  the  number  of  elements  incorrectly 
received  to  the  total  number  of  elements  sent. 
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Equipment, 

Off-Line 


Equipment, 

On-Line 


Error,  Data 

Error,  Machine 

Executive 
Facsimile  (FAX) 

Field 

Field,  Card 

File 


The  peripheral  equipment  or  devices  not  in  di¬ 
rect  communication  with  the  central  processing 
unit  of  a  computer.  Synonymous  with  auxiliary 
equipment. 

Descriptive  of  a  computer  system  and  of  the  pe¬ 
ripheral  equipment  or  devices  in  a  computer 
system  in  which  the  operation  of  such  equip¬ 
ment  is  under  control  of  the  central  processing 
unit  (CPU),  and  in  which  information  reflecting 
current  activity  is  introduced  into  the  data  proc¬ 
essing  system  as  soon  as  it  occurs.  Thus,  di¬ 
rectly  in-line  with  the  main  flow  of  transaction 
processing.  Related  to  on-line  processing. 

A  deviation  from  correctness  in  data,  usually 
an  error,  which  occurred  prior  to  processing 
the  data. 

A  deviation  from  correctness  in  data  resulting 
from  an  equipment  failure. 

(See  "Routine,  Executive.") 

Transmission  of  pictures,  maps,  diagrams,  etc., 
by  wire.  The  image  is  scanned  at  the  transmitter 
and  reconstructed  at  the  receiving  station. 

A  specified  area  of  a  record  used  for  a  particu¬ 
lar  category  of  data;  e.g.,  a  group  of  card 
columns  used  to  represent  a  wage  rate  or  a  set 
of  bit  locations  in  a  computer  word  used  to  ex¬ 
press  the  address  of  the  operand. 

A  set  of  card  columns,  either  fixed  as  to  num¬ 
ber  and  position,  or,  if  variable,  then  identifi¬ 
able  by  position  relative  to  other  fields.  Cor¬ 
responding  fields  on  successive  cards  are 
normally  used  to  store  similar  information. 

A  collection  of  related  records.  For  example, 
in  inventory  control,  one  line  of  an  invoice  con¬ 
taining  data  on  the  material,  the  quantity,  and 
the  price  forms  an  item;  a  complete  invoice 
forms  a  record;  and  the  complete  set  of  such 
records  forms  a  file. 


File  Conversion 


FORTRAN 

Functional  Analysis 

Functional  Area 

Function, 

Processing 

Hardware 

HEDCOM 

Input 

Input,  Batched 

Input,  Unbatched 


A  process  for  preparing  the  data  base  of  an 
ADPS  to  enable  the  ADPS  to  become  operational. 

In  file  conversion  all  necessary  files  of  the  data 
base  are  converted  from  their  present  format 
(magnetic  tape,  punched  cards,  hardcopy,  etc.) 
to  their  required  format  in  the  ADPS  about  to 
become  operational. 

Formula  Translation;  a  programming  language 
designed  primarily  for  problems  that  can  be  ex¬ 
pressed  in  algebraic  notation.  The  original 
version  of  FORTRAN  has  been  extended  to  in¬ 
clude  Boolean  expressions,  hierarchies  of  sub¬ 
routines  sharing  common  storage,  and  insertion 
of  symbolic  language  sequences. 

Application- oriented  analysis  and  research  re¬ 
quired  to  support  ADPS  design  and  implementa¬ 
tion.  This  effort  usually  takes  place  very  early 
in  the  development  phase  and  is  independent  of 
any  particular  implementation  methodology. 

Any  one  of  the  broad  application  categories  such 
as  payroll,  accounting,  inventory  control,  weather 
forecasting,  etc. 

A  set  of  computer  instructions  performing  com¬ 
putational,  decisional,  or  data  manipulation  op¬ 
erations.  Processing  functions  maybe  categor¬ 
ized  as  input  edit,  sort,  report  generation,  etc. 

The  physical  equipment  or  devices  of  a  com¬ 
puter  and  peripheral  equipment. 

Headquarters  Command 

(1)  Data  supplied  to  a  system  from  an  external 
source  for  processing;  (2)  the  process  of  trans¬ 
ferring  data  from  an  external  to  an  internal 
storage. 

(1)  Any  set  of  inputs  collected  together  as  a 
group  before  submittal  for  computer  processing. 
The  collected  groups  are  called  batches.  (2)  Any 
input  that  is  not  unbatched. 

Input  that  is  entered  directly  into  the  computer 
as  it  is  received  via  an  on-line  input  device. 
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Input  Edit 

A  computer  processing  function  performed  on 
input  data  to  prepare  them  for  the  primary 
processing;  e.g.,  limit  and  logic  checking, 
field  conversion,  and  data  edit. 

Instruction 

An  operation  and  the  values  or  locations  of  all 
operands  associated  with  the  operation. 

Instruction, 

Multiple  Address 

An  instruction  consisting  of  an  operation  code 
and  two  or  more  addresses.  Usually  specified 
as  a  two-address,  three-address,  or  four- 
address  instruction. 

Instruction,  Object 

An  instruction  in  the  machine  language  of  the 
computer  on  which  the  instruction  is  to  be 
executed. 

Instruction,  One 
Address 

An  instruction  consisting  of  an  operation  and 
exactly  one  address.  The  instruction  code  of 
a  single  address  computer  may  include  both 
zero-  and  multi-address  instructions  as  spe¬ 
cial  cases. 

Iso-Graph 

A  planar  diagram  of  a  function  of  two  variables, 
representing  values  of  the  function  by  lines  of 
constant  function  value  (iso-lines). 

Iso- Line 

A  straight  or  curved  line  on  an  iso- graph  along 
which  there  is  a  constant  value. 

Language,  Source 

A  language  in  the  form  of  written  statements 
that  is  an  input  to  a  given  translation  process 
usually  resulting  in  object  instructions. 

Language,  Target 

A  language  that  is  an  output  from  a  given  trans¬ 
lation  process . 

Library- 

(1)  A  collection  of  information  available  to  a 
computer,  usually  on  magnetic  tapes;  (2)  lo¬ 
cation  of  the  collection  of  magnetic  tapes. 

Library,  Routine 

A  collection  of  standard  proven  routines  and 
subroutines  by  which  problems  and  parts  of 
problems  may  be  solved. 

Logical  Record 

A  set  of  logically  related  data  fields  independent 
of  the  physical  manner  of  representation. 
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MAC 


MAFR 

Maintenance, 

Maintenance, 

Preventive 

Maintenance, 

Program 

Maintenance, 

Remedial 


Manager 


Merge 


MILSTAMP 


MILSTRIP 


Module 


(1)  Military  Airlift  Command,  a  major  Air 
Force  command,  formerly  MATS  (Military 
Air  Transport  Service),  (2)  Major  Air  Com¬ 
mand;  any  one  of  the  Air  Force  commands 
such  as  SAC,  TAC,  PACAF,  ATC,  etc. 

Merged  Accountability  and  Fund  Reporting; 
an  Air  Force  central  accounting  system. 

File  A  computer  processing  function  for  modifica¬ 

tion  of  a  file  to  incorporate  corrections,  ad¬ 
ditions,  and  deletions. 

The  maintenance  of  a  set  of  hardware  that  at¬ 
tempts  to  keep  equipment  in  top  operating  con¬ 
dition  and  to  preclude  failures  during  production 
runs . 

The  process  of  improving,  changing,  and  cor¬ 
recting  programs  of  a  system  that  is  currently 
operational. 

The  maintenance  performed  by  the  contractor 
following  equipment  failure;  therefore,  is  per¬ 
formed  as  required,  on  an  unscheduled  basis. 

An  individual  responsible  for  directing  and  co¬ 
ordinating  all  or  part  of  the  activities  associated 
with  an  ADPS.  Only  managers  devoting  at  least 
10  percent  of  their  time  to  a  system  are  con¬ 
sidered  part  of  that  system1  s  personnel. 

A  computer  processing  function  that  combines 
items  or  records  from  two  or  more  sequenced 
files  with  the  same  key  into  one  sequenced  file. 

Military  Standard  Transportation  and  Movement 
Procedures;  a  DOD  standard  for  worldwide  ship¬ 
ment  transportation  activities. 

Military  Standard  Requisitioning  and  Issue  Pro¬ 
cedures;  a  DOD  standard  for  procurement  and 
issuance  of  inventory  items. 

(1)  An  interchangeable  plug-in  item  containing 
components;  (2)  an  incremental  block  of  stor¬ 
age  or  other  building  block  for  expanding  the 
computer  capacity. 
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Multiplex 

The  process  of  transferring  data  from  several 
storage  devices  operating  at  relatively  low 
transfer  rates  to  one  storage  device  operating 
at  a  high  transfer  rate  in  such  a  manner  that  the 
high-speed  device  is  not  obliged  to  wait  for  the 
low- speed  devices. 

Multiprocessing 

A  mode  of  hardware  operation  where  two  or 
more  instruction  sequences  may  be  executed 
simultaneously.  The  instruction  sequences  may 
be  part  of  the  same  program  or  different  pro¬ 
grams.  When  the  instruction  sequences  are 
from  different  programs,  the  hardware  opera¬ 
tion  is  also  multiprog  rammed. 

Multiprogramming 

The  interleaved  or  simultaneous  execution  of 
two  or  more  programs  by  interconnected 
hardware. 

Off-  Line 

Pertaining  to  peripheral  equipment  or  devices 
not  in  direct  communication  with  the  central 
processing  unit  (CPU)  of  a  computer.  Clarified 
by  11  Equipment,  Off- Line.” 

OI 

Office  Instruction 

On-Line 

Pertaining  to  peripheral  equipment  or  devices 
in  direct  communication  with  the  central  proc¬ 
essing  unit  (CPU)  of  a  computer.  Clarified  by 
nEquipment,  On-Line”;  synonymous  with  in¬ 
line  processing  and  on-line  processing. 

Open  Shop 

See  nShop,  Open.” 

Operand 

A  quantity  entering  or  arising  in  an  instruction. 
An  operand  may  be  an  argument,  a  result,  a 
parameter,  or  an  indication  of  the  location  of 
the  next  instruction,  as  opposed  to  the  operation 
code  itself. 

Operations, 

Computer 

That  part  of  ADP  activity  required  for  running 
production  and/or  development  programs  on 

ADP  equipment. 

Operator 

(1)  In  the  description  of  a  process,  that  which 
indicates  the  action  to  be  performed  on  operands; 

(2)  a  person  who  operates  a  machine. 
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Output 

(1)  Those  data  that  have  been  processed  as  an 
ultimate  system  product;  (2)  the  process  of 
transferring  data  from  an  internal  storage  to 
an  external  storage. 

Output,  Direct 

Data  produced  on  an  on-line  output  device  while 
the  user  is  in  attendance. 

Output,  Indirect 

Data  disseminated  to  a  user  via  manual  handling 
subsequent  to  its  production  on  an  output  device. 

PCAM 

Punched  Card  Accounting  Machine;  the  set  of  con¬ 
ventional  punch  card  equipment  including  sorters, 
collators,  and  tabulators. 

PDSA 

Personnel  Data  System--Airmen;  a  centralized 
Air  Force  data  processing  system  to  maintain 
airman  personnel  data. 

PDSO 

Personnel  Data  System--Officer s;  a  centralized 
Air  Force  data  processing  system  to  maintain 
officer  personnel  data. 

Preparation, 

Application 

(See  "Application  Preparation.11) 

Programmer 

A  person  who  prepares  problem-solving  pro¬ 
cedures  and  logical  flow  charts  and  who  codes 
and  debugs  programs. 

Production 

Any  computer  processing  resulting  in  the  gen¬ 
eration  of  output  to  users. 

Production, 

Application 

(See  11  Application  Production.") 

Query 

A  computer  processing  function  acting  on  a  de¬ 
mand  input  which  specifies  that  data  be  accessed 
via  file  search  and  be  displayed  or  output. 

RAFT 

Regional  Accounting  and  Finance  Test;  a  pilot 

Air  Force  data  processing  system  for  testing 
a  USAF  base-level  regional  accounting  and  fi¬ 
nance  system  concept. 

Ratio,  Operating 

The  ratio  of  the  number  of  hours  of  correct  ma¬ 
chine  operation  to  the  total  hours  of  scheduled 
operation;  e.g.,  on  a  1  68-hour- week  scheduled 
operation,  if  12  hours  of  preventive  maintenance 
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Real-Time 

are  required  and  4.8  hours  of  unscheduled 
downtime  occurs,  then  the  operating  ratio  is 
(168  -  1 6.8)  / 1 68 ,  which  is  equivalent  to  a 

90  percent  operating  ratio. 

(1)  Pertaining  to  the  actual  time  during  which  a 
physical  process  transpires;  (2)  pertaining  to 
the  performance  of  a  computation  during  the 
actual  time  that  the  related  physical  process 
transpires  so  that  results  of  the  computations 
can  be  used  in  guiding  the  physical  process. 

Record 

(1)  A  group  of  related  fields  of  information 
treated  as  a  unit;  (2)  to  put  data  into  a  storage 
device. 

Record,  Unit 

A  separate  record  that  is  similar  in  form  and 
content  to  other  records;  e.g.,  a  summary  of 
a  particular  employee's  earnings  to  date. 

Reliability 

(1)  A  measure  of  the  ability  to  function  without 
failure;  (2)  the  amount  of  credence  placed  in  a 
result. 

Relocate 

In  programming,  to  move  a  routine  from  one 
portion  of  storage  to  another  and  to  adjust  the 
necessary  address  references  so  that  the  rou¬ 
tine  can  be  executed  in  its  new  location. 

Report  Generation 

A  computer  processing  function  that  transforms 
results  from  the  primary  computation  to  outputs 
for  the  system  user;  e.g.,  data  edit,  formatting, 
and  printing. 

Response 

The  response  of  a  device  or  system  is  a  quanti¬ 
tative  expression  of  the  output  as  a  function  of 
the  input  under  conditions  that  must  be  ex¬ 
plicitly  stated. 

Routine 

A  set  of  coded  instructions  arranged  in  proper 
sequence  to  direct  the  computer  to  perform  a 
desired  operation  or  sequence  of  operations. 

A  subdivision  of  a  program  consisting  of  two 
or  more  instructions  that  are  functionally  re¬ 
lated;  therefore,  a  program. 

Routine,  Debugging 
Aid 

A  routine  to  aid  programmers  in  the  debugging 
of  their  routines.  Some  typical  routines  are 
storage  printout,  tape  printout,  and  drum  print¬ 
out  routines. 
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Routine,  Executive 

A  routine  that  controls  loading  and  relocation 
of  routines  and  in  some  cases  makes  use  of 
instructions  that  are  unknown  to  the  general 
programmer.  Effectively,  an  executive  routine 
is  part  of  the  machine  itself. 

Routine,  Service 

A  broad  class  of  routines  that  are  standardized 
at  a  particular  installation  for  the  purpose  of 
assisting  in  maintenance  and  operation  of  the 
computer  as  well  as  in  the  preparation  of  pro¬ 
grams,  as  opposed  to  routines  for  the  actual 
solution  of  production  problems.  This  class 
includes  monitoring  or  supervisory  routines, 
assemblers,  compilers,  diagnostics  for  com¬ 
puter  malfunctions,  simulation  of  peripheral 
equipment,  general  diagnostics,  and  input  data. 
The  distinguishing  quality  of  service  routines 
is  that  they  are  generally  standardized  to  meet 
the  servicing  needs  at  a  particular  installation, 
independent  of  any  specific  production-type  rou¬ 
tine  requiring  such  services. 

Routine,  Utility 

A  standard  routine  used  to  assist  in  the  operation 
of  the  computer;  e.g.,  a  conversion  routine,  a 
sorting  routine,  a  printout  routine,  or  a  tracing 
routine.  Synonymous  with  utility  program. 

Run 

The  performance  of  one  or  more  programs  on 
a  computer;  thus,  the  performance  of  one  rou¬ 
tine  or  several  routines  linked  so  that  they  form 
an  automatic  operating  unit,  during  which  manual 
manipulations  by  the  computer  operator  are  zero, 
or  at  least  minimal. 

SAC 

Strategic  Air  Command 

Shop,  Closed 

The  operation  of  a  computer  facility  where  pro¬ 
gramming  service  to  the  user  is  the  responsi¬ 
bility  of  a  group  of  specialists,  thereby  effec¬ 
tively  separating  the  phase  of  task  formation 
from  that  of  computer  implementation.  The  pro¬ 
grammers  are  not  allowed  in  the  computer  room 
to  run  or  oversee  the  running  of  their  programs. 
Contrasted  with  "Shop,  Open.11 

Shop,  Open 

The  operation  of  a  computer  facility  where  com¬ 
puter  programming,  coding,  and  operating  can 
be  performed  by  any  qualified  employee  of  the 
organization,  not  necessarily  by  the  personnel 

Software 

of  the  computing  center  itself;  and  where  the 
programmer  may  assist  in  or  oversee  the  run¬ 
ning  of  his  program  on  the  computer.  Contrasted 
with  "Shop,  Closed." 

The  totality  of  programs  and  routines  used  to 
extend  the  capabilities  of  computers,  such  as 
compilers,  assemblers,  narrators,  routines, 
and  subroutines.  Contrasted  with  "Hardware." 

Sort 

(1)  To  arrange  items  of  information  according 
to  rules  dependent  upon  a  key  or  field  contained 
in  the  items  or  records;  (2)  a  computer  proc¬ 
essing  function  to  arrange  records  of  informa¬ 
tion  according  to  rules  operating  upon  key(s) 
contained  in  the  records. 

Statement,  Source 

In  computer  programming,  a  meaningful  ex¬ 
pression  or  generalized  instruction  in  a  source 
language. 

Storage,  Auxiliary 

A  storage  device  in  addition  to  the  main  storage 
of  a  computer;  e.g.,  magnetic  tape,  disk,  or 
magnetic  drum.  Auxiliary  storage  usually  holds 
much  larger  amounts  of  information  than  the 
main  storage,  and  the  information  is  less  rap¬ 
idly  accessible. 

Storage,  Main 

Usually  the  fastest  storage  device  of  a  computer 
and  the  one  from  which  instructions  are  executed. 

System,  Automatic 
Data  Processing 

The  term  descriptive  of  an  interacting  assembly 
of  procedures,  processes,  methods,  personnel, 
and  automatic  data  processing  equipment  which 
performs  a  complex  series  of  data  processing 
operations . 

System  Analyst 

A  person  skilled  in  the  definition  and  development 
of  techniques  for  solving  a  problem.  System  ana¬ 
lysts  are  usually  specialists  in  a  particular  class 
of  problems  such  as  inventory,  accounting,  com¬ 
mand  and  control,  etc. 

TAC 

Tactical  Air  Command 

Terminal 

(1)  A  point  in  a  system  or  communication  net¬ 
work  at  which  data  can  either  enter  or  leave; 

(2)  a  general  term  referring  to  the  equipment 
at  the  end  of  a  telegraph  circuit;  modems  and 
associated  equipment. 
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Test,  Program 

A  system  of  checking  before  running  any  prob¬ 
lem  in  which  a  sample  problem  of  the  same  type 
with  a  known  answer  is  run. 

Test,  System 

(1)  The  running  of  the  whole  system  against 
test  data;  (2)  a  complete  simulation  of  the 
actual  running  system  for  purposes  of  testing 
the  adequacy  of  the  system;  (3)  a  test  of  an 
entire  interconnected  set  of  components  for 
the  purpose  of  determining  proper  functioning 
and  interconnection. 

Throughput 

Productivity  based  on  all  facets  of  an  operation. 
For  example,  a  computer  with  a  capability  of 
simultaneous  operations  (e.g.,  read/write/ 
compute)  would  have  a  high  throughput  rating. 

Time,  Application 
Preparation 

Any  computer  processing  involved  in  initial  file 
development  and  other  one-time  operations  when 
converting  an  application,  including  parallel 
operations . 

Time,  Application 
Production 

Any  computer  processing  of  an  application  re¬ 
sulting  in  the  generation  of  output  to  the  applica¬ 
tion  user(s). 

Time,  Available 

(1)  The  number  of  hours  a  computer  is  available 
for  use;  (2)  the  time  during  which  a  computer 
has  the  power  turned  on,  is  not  under  mainte¬ 
nance,  and  is  known  or  believed  to  be  operating 
correctly. 

Time,  Chargeable 
Lost 

This  time  may  be  attributed  to  the  following: 

(a)  Programming  Error:  Rerun  time  as  a  re¬ 
sult  of  program  errors,  (b)  Operator  Error: 
Rerun  time  as  a  result  of  computer  operator 
errors,  (c)  Defective  Tape:  Rerun  time  as  a 
result  of  magnetic  tape  defects  when  such  time 
is  not  gratuitously  provided,  (d)  Scheduling 

Error:  Rerun  time  when  a  program  run  is  proc¬ 
essed  out  of  sequence  with  incomplete  data, 
etc.,  because  of  an  erroneous  schedule,  (e)  De¬ 
fective  Materials:  Rerun  time  due  to  material 
defects  other  than  magnetic  tape;  i.e.  ,  bad  paper, 
card  defects,  poor  printer  ribbons,  etc.  (f)  In¬ 
correct  Data:  Rerun  time  caused  by  erroneous 
input  data  received  from  another  organization 
or  other  data,  (g)  Site  Environment  Failures: 

180 


Time,  Down 


Time,  Idle 


Time,  Machine 
Error  Lost 

T  ime ,  Off 


Time,  Operational 
Use 


T  ime ,  Othe  r 


Time,  Program 
Development  and 
Maintenance 


Time,  Program 
Testing 


Rerun  time  caused  by  an  air  conditioning  failure, 
electric  power  failure,  or  other  site  phenomenon 
that  interrupts  processing,  (h)  Other  Chargeable 
Rerun:  Rerun  time  caused  by  factors  other  than 
above. 

The  period  during  which  a  computer  is  malfunc¬ 
tioning  or  not  operating  correctly  because  of 
mechanical  or  electronic  failure,  as  opposed  to 
available  time,  idle  time,  or  standby  time,  dur¬ 
ing  which  the  computer  is  functional.  Contrasted 
with  "Time,  Up." 

That  time,  scheduled  or  unscheduled,  which  nor¬ 
mally  occurs  between  completing  of  one  program 
run  (end  of  tear  down)  and  starting  to  set  up  for 
the  next  program  run.  Idle  time  may  also  occur 
during  a  run  period.  Idle  time  also  includes  that 
portion  of  time  the  computer  system  cannot  be 
used  because  of  site  environment  failure. 

Rerun  time  provided  by  the  vendor  as  a  result 
of  computer  system  failure. 

Time  when  the  computer  system  is  not  scheduled 
to  operate.  (Usually  occurs  on  weekends,  holi¬ 
days,  and  late  evening  or  early  morning  hpurs.) 

In  Federal  Government  ADP  contracts,  the  time 
during  which  the  equipment  is  in  operation,  ex¬ 
clusive  of  idle  time,  setup  time,  maintenance 
time,  or  rerun  time  due  to  machine  failure. 
Components  not  programmed  for  use  in  a  spe¬ 
cific  computer  run  are  not  considered  to  be  in 
use,  even  though  connected  into  the  computer 
system. 

Time  when  no  other  classification  of  time  is 
applicable  or  when  the  classification  of  time 
is  not  available  or  unknown. 

The  computer  time  for  chargeable  program  de¬ 
velopment  and  maintenance,  including  assembly, 
compilation,  test,  and  maintenance.  (Mainte¬ 
nance  refers  to  time  spent  in  changing,  improv¬ 
ing,  and  patching  of  existing  programs.) 

The  machine  time  expended  for  program  testing, 
debugging,  and  volume  and  compatibility  testing. 
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Time,  Search 

The  time  required  to  locate  a  particular  field 
of  data  in  storage.  Searching  requires  a  com¬ 
parison  of  each  field  with  a  predetermined 
standard  until  an  identity  is  obtained.  This  is 
contrasted  with  access  time,  which  is  based  on 
locating  data  by  means  of  the  address  of  its  stor¬ 
age  location. 

Time,  Scheduled 
Maintenance 

Time  during  which  the  computer  system  is  placed 
at  the  disposal  of  the  engineer  for  scheduled  pre¬ 
ventive  maintenance  and  during  which  maintenance 
is  actually  performed. 

Time,  Setup 

Time  required  to  load  and  unload  tape  drives 
and  card  readers,  to  insert  printer  forms,  etc., 
when  the  CPU  is  not  processing.  Such  time  may 
occur  at  the  beginning  of,  during,  or  at  the  end 
of,  a  processing  run  and  includes  temporary  de¬ 
lays,  such  as  correcting  card  and  paper  jams. 

Time -Sharing 

(1)  The  use  of  a  device  for  two  or  more  pur¬ 
poses  during  the  same  overall  interval,  accom¬ 
plished  by  interspersing  component  actions  in 
time;  (2)  pertaining  to  the  interleaved  use  of  the 
time  of  a  device. 

Time,  System 
Improvement 

The  machine  downtime  needed  for  the  installation 
and  testing  of  new  components,  large  or  small, 
and  machine  downtime  necessary  for  modifica¬ 
tion  of  existing  components.  This  includes  ail 
programmed  tests  following  the  above  actions  to 
prove  the  machine  is  operating  properly. 

Time,  Turnaround 

The  average  time  required  by  a  computer  opera¬ 
tions  unit  to  complete  a  program  compilation  or 
test,  including  time  waiting  in  queue  of  jobs  to 
be  run. 

Time,  Unscheduled 
Maintenance 

Time  during  which  the  computer  system  is  down 
due  to  a  machine  malfunction.  The  computer 
system  is  considered  down  when  it  is  not  used 
because  one  or  more  components  are  down.  Re¬ 
medial  maintenance  is  performed  during  this  time. 

Time,  Up 

The  time  during  which  equipment  is  either  pro¬ 
ducing  work  or  is  available  for  productive  work. 

T  race 

An  interpretive  diagnostic  technique  that  provides 
an  analysis  of  each  executed  instruction. 
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Transport,  Tape 

The  mechanism  that  moves  magnetic  or  paper 
tape  past  sensing  and  recording  heads;  usually 
associated  with  data  processing  equipment. 
Sometimes  called  tape  drive. 

Update 

To  put  into  a  file  changes  required  by  current 
information  or  transactions. 

USAF 

United  States  Air  Force 

Workload 

The  external  aspects  of  information  flow  asso¬ 
ciated  with  an  ADPS.  Workload  is  broken  into 
the  following  major  areas:  inputs,  outputs, 
data  base,  and  processing  functions.  Each 
major  area  is  further  broken  into  components 
such  as  input  volume,  output  volume,  and  data 
base  size. 

Workload  Descriptor 

A  measurable  numeric  quantity  defining  the  mag 
nitude  of  workload  components  such  as  input 
volume,  output  variety,  and  data  base  size. 
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B. 


Glossary  of  Cost  Factors  and  Workload  Descriptors 


Average  Number  of  Years 
of  ADP  Experience  for 
Analysts 


Average  Number  of  Years 
of  ADP  Experience  for 
Development  Managers 

Average  Number  of  Years 
of  ADP  Experience  for 
Operations  Personnel 


Average  Number  of  Years 
of  ADP  Experience  for 
P  r  og  ramme  r  s 


Average  number  of  Years 
of  College  Education  for 
Development  Managers 


Average  Number  of  Years 
of  Functional  Area  Ex¬ 
perience  for  Analysts 


Average  number  of  years  in  ADP  for  ana¬ 
lysts,  who  are  persons  skilled  in  the  def¬ 
inition  and  development  of  techniques  for 
solving  a  problem. 

Average  number  of  years  in  the  field  of 
automatic  data  processing  (ADP)  for  de¬ 
velopment  managers. 

Average  number  of  years  in  ADP  for  op¬ 
erations  personnel,  including  operators, 
schedulers,  data  edit  personnel,  magnetic 
type  librarians,  report  binders ,  and 
managers. 

Average  number  of  years  in  ADP  for  pro¬ 
grammers,  who  are  persons  who  prepare 
problem-solving  procedures  and  logical 
flow  charts,  and  code  and  debug  programs. 

Development  managers'  college  education, 
measured  in  average  number  of  years, 
where  development  managers  are  the  in¬ 
dividuals  responsible  for  directing  and 
coordinating  all  or  part  of  the  activities 
associated  with  an  ADPS  during  the  de¬ 
velopment  phase.  Only  managers  devot¬ 
ing  at  least  10  percent  of  their  time  to  the 
system  are  considered. 

Average  number  of  years  of  experience  in 
a  field  of  application  for  analysts,  who  are 
persons  skilled  in  the  definition  and  develop¬ 
ment  of  techniques  for  solving  a  problem. 


Average  Number  of  Years 
of  Functional  Area  Expe¬ 
rience  for  Development 
Managers 


Average  number  of  years  of  experience  in 
a  field  of  application  such  as  accounting, 
inventory  control,  weather  forecasting, 
etc.,  for  development  managers,  where 
development  managers  are  the  individuals 
responsible  for  directing  and  coordinating 
all  or  part  of  the  activities  associated  with 
an  ADPS  during  the  development  phase. 
Only  managers  devoting  at  least  10  percent 
of  their  time  to  the  system  are  considered. 


185 


Average  Number  of  Years 
of  Functional  Area  Expe¬ 
rience  for  Operations 
Personnel 

Average  number  of  years  of  experience  in 
a  field  of  application  for  operations  person¬ 
nel,  including  operators,  schedulers,  data 
edit  personnel,  magnetic  tape  librarians, 
report  binders,  and  managers. 

Average  Number  of  Years 
of  Functional  Area  Expe¬ 
rience  for  Programmers 

Average  number  of  years  of  experience  in 
a  field  of  application  for  programmers,  who 
are  persons  who  prepare  problem-solving 
procedures  and  flow  charts,  and  code  and 
debug  programs. 

Characters  in  Data  Base 

The  expected  number  of  characters  in  the 
data  base  where  the  data  base  is  a  collec¬ 
tion  of  files  that  contain  unique  informa¬ 
tion,  are  accessible  to  the  ADPS,  and  are 
normally  referenced  or  updated  with  rela¬ 
tively  high  frequency.  Intermediate  files 
are  not  counted. 

Characters  Per  Month 
of  Input  Volume 

The  expected  amount  of  ADPS  input  orig¬ 
inating  outside  the  ADPS,  measured  in 
characters  per  month.  Intermediate  in¬ 
puts  of  the  ADPS  should  not  be  included. 

On  unit  record  input,  only  character  posi¬ 
tions  used  for  data  are  counted. 

Characters  Per  Month 
of  Output  Volume 

The  expected  amount  of  ADPS  output  des¬ 
tined  to  users,  measured  in  characters 
per  month.  Intermediate  outputs  of  the 
ADPS  are  not  included.  Only  nonblank 
characters  are  counted. 

Dollars  of  Hardware  Cost 
for  Program  Checkout 

The  hardware  cost  for  computer  hours 
used  for  program  checkout  during  the  de¬ 
velopment  phase  of  the  ADPS. 

Dollars  Per  Month  of 
Hardware  Cost  for 
Application  Production 

The  hardware  cost  for  monthly  computer 
hours  charged  to  the  user  of  the  ADPS  for 
processing  that  is  not  of  a  developmental 
or  corrective  nature. 

Dollars  Per  Month  of 
Hardware  Cost  for 

Program  Maintenance 

The  hardware  cost  for  the  monthly  com¬ 
puter  hours  used  for  processing  improve¬ 
ments,  changes,  and  corrections  to  pro¬ 
grams  of  an  operational  ADPS. 
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Man-Months  of 
Development  Effort 


Months  of  Elapsed 
Development  Time 


The  number  of  man-months  expended  by  all 
relevant  personnel,  including  managers, 
analysts,  programmers,  and  operators,  to 
develop  the  ADPS  during  the  development 
phase,  which  begins  with  the  start  of  sys¬ 
tem  design  and  ends  when  the  system  is 
declared  operational.  During  this  develop¬ 
ment  phase  such  activities  as  detailed  sys¬ 
tem  design,  programming,  checkout,  and 
equipment  installation  are  accomplished. 

The  number  of  calendar  months  elapsed 
from  the  date  system  design  for  the  ADPS 
is  begun  to  the  date  it  is  declared  operational. 


Number  of  Data 
Base  Record  Types 


Number  of  Input 
Data  Fields 


Number  of  Input 
Transaction  Types 


Number  of  Object 
Instructions 


Number  of  Output 
F  or  mats 

Number  of  Operations 
Personnel 


Number  of  Program 
Maintenance  Personnel 


The  number  of  logical  record  types  in  the 
data  base  where  a  logical  record  is  a  set 
of  logically  related  data  fields  independent 
of  the  physical  manner  of  storage. 

A  count  of  data  fields  from  the  ADPS  input 
that  are  unique  in  content  and/or  format; 
e.  g.  ,  if  there  is  a  data  field  for  name  on 
six  different  card  formats,  the  number  of 
unique  data  fields  is  one. 

A  count  of  different  transaction  types  of 
ADPS  input  that  normally  are  identified 
by  a  unique  transaction  code  and/or  a 
unique  input  format. 

The  number  of  instructions  generated  by 
the  compiler  or  assembler  for  the  ADPS. 
This  is  the  number  of  machine-format  in¬ 
structions  in  an  object  program  deck  that 
can  be  processed  directly  by  the  computer. 

The  number  of  different  types  and  formats 
of  ADPS  outputs . 

The  number  of  personnel,  including  op¬ 
erators,  schedulers,  data  edit  personnel, 
magnetic  tape  librarians,  report  binders, 
and  managers,  etc.,  used  to  process  the 
ADPS  programs  on  the  computer  during 
the  operations  phase. 

The  number  of  personnel,  including  man¬ 
agers,  analysts,  and  programmers,  in¬ 
volved  in  improving,  changing,  and  cor¬ 
recting  programs  of  a  system  during  the 
operations  phase. 
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Number  of  Source 
Statements 

The  number  of  lines  of  code  written  by  the 
programmer  in  any  source  language  for  the 

ADPS.  This  may  be  the  same  as  the  num¬ 
ber  of  instructions  in  machine  language. 

Percent  of  Input 

Rejects 

Input  data  error  rate,  measured  by  the 
ratio  of  the  number  of  rejected  records 
to  the  number  of  expected  records  per 
month  multiplied  by  100. 

Percent  of  Production 
Hours  for  Compute 

The  percent  of  production  hours  per  month 
for  compute,  where  compute  is  the  per¬ 
formance  of  logical,  arithmetic,  and  de¬ 
cisional  operations  on  data. 

Percent  of  Production 
Hours  for  Control 

The  percent  of  production  hours  per  month 
for  control,  where  control  is  a  computer 
processing  function  that  expedites  all  other 
computer  processing  functions;  e.g.,  job 
scheduling,  priority  handling,  segment 
overlaying,  data  management,  and  hard¬ 
ware  assignment,  etc. 

Percent  of  Production 
Hours  for  File 
Maintenance 

The  percent  of  production  computer  hours 
per  month  for  file  maintenance,  where  file 
maintenance  is  the  modification  of  a  file  to 
incorporate  corrections,  additions,  and 
deletions. 

Percent  of  Production 
Hours  for  Input  Edit 

The  percent  of  production  computer  hours 
per  month  for  input  edit,  where  input  edit 
is  performed  on  input  data  to  prepare  it 
for  the  primary  processing;  e.g.,  limit 
and  logic  checking,  field  conversion,  and 
data  edit. 

Percent  of  Production 
Hours  for  Merge 

The  percent  of  production  computer  hours 
per  month  for  merge,  where  merge  is  the 
combining  of  items  or  records  from  two 
or  more  sequenced  files  with  the  same 
key  into  one  sequenced  file. 

Percent  of  Production 
Hours  for  Query 

The  percent  of  production  hours  per  month 
for  query,  where  query  is  action  on  a  de¬ 
mand  input  which  specifies  that  data  be 
accessed  via  file  search  and  displayed  or 
output . 

Percent  of  Production 
Hours  for  Report 
Generation 

The  percent  of  production  computer  hours 
per  month  for  report  generation,  where 
report  generation  is  the  transformation 
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of  results  from  primary  computations  to 
outputs  for  the  system  user. 


Percent  of  Production 

Hours  for  Sort 

The  percent  of  production  hours  per  month 
for  sort,  where  sort  is  the  arranging  of 
records  of  information  according  to  rules 
operating  upon  key(s)  contained  in  the 
records . 

Percent  of  Source  State¬ 
ments  for  Compute 

The  percent  of  source  statements  for  com¬ 
pute,  where  compute  is  the  performance 
of  logical,  arithmetic,  and  decisional  op¬ 
erations  on  data. 

Percent  of  Source  State¬ 
ments  for  Control 

The  percent  of  source  statements  for  con¬ 
trol,  where  control  is  a  computer  process¬ 
ing  function  that  expedites  all  other  com¬ 
puter  processing  functions;  e.g.,  job 
scheduling,  priority  handling,  segment 
overlaying,  data  management,  and  hard¬ 
ware  assignment. 

Percent  of  Source  State¬ 
ments  for  File  Maintenance 

The  percent  of  source  statements  for  file 
maintenance,  where  file  maintenance  is 
the  modification  of  a  file  to  incorporate 
corrections,  additions,  and  deletions . 

Percent  of  Source  State¬ 
ments  for  Input  Edit 

The  percent  of  source  statements  for  input 
edit,  where  input  edit  is  performed  on  input 
data  to  prepare  it  for  the  primary  process¬ 
ing;  e.  g.  ,  limit  and  logic  checking,  field 
conversion,  and  data  edit. 

Percent  of  Source  State¬ 
ments  for  Merge 

The  percent  of  source  statements  for  merge, 
where  merge  is  the  combining  of  items  or 
records  from  two  or  more  sequenced  files 
with  the  same  key  into  one  sequenced  file. 

Percent  of  Source  State¬ 
ments  for  Query 

The  percent  of  source  statements  for  query, 
where  query  is  action  on  a  demand  input 
which  specifies  that  data  be  accessed  via 
file  search  and  displayed  or  output. 

Percent  of  Source  State¬ 
ments  for  Report 

Generation 

The  percent  of  source  statements  for  re¬ 
port  generation,  where  report  generation 
is  the  transformation  of  results  from  pri¬ 
mary  computations  to  outputs  for  the  sys¬ 
tem  user. 
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Percent  of  Source 
Statements  for  Sort 


The  percent  of  source  statements  for  sort, 
where  sort  is  the  arranging  of  records  of 
information  according  to  rules  operating 
upon  key(s)  contained  in  the  record. 
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Use  of  the  Development  Experience  Index 

The  development  experience  index  is  used  to  retrieve  relevant 
development  experience  from  the  system  descriptions.  Retrieval 
is  based  on  the  following  workload  descriptors: 

Number  of  Input  Transaction  Types 
Number  of  Input  Data  Fields 
Number  of  Output  Formats 
Number  of  Data  Base  Record  Types 

Proposed  values  of  these  workload  descriptors  must  be  known  for 
the  ADPS  under  evaluation.  The  type  of  development  experience 
and  problems  retrieved  by  this  index  will  be  related  to  the  magni¬ 
tude  of  the  development  effort.  Sections  of  system  descriptions 
which  will  be  of  greatest  interest  include: 

Application  Program  Development 
Application  Program  Maintenance 

Other  sections  of  interest  include: 


Schedule 


Organization 

History 

Software 


File  Conversion 

Documentation 

Personnel 


Benefits 
Cost  Factors 
Description 


Procedure 

1.  Enter  the  proposed  values  for  No.  of  Input  Transaction  Types,  No.  of  Input  Data  Fields,  No.  of  Output 
Formats,  and  No.  of  Data  Base  Record  Types  in  box  below  the  corresponding  scale. 

2.  Remove  the  index  card  from  the  pocket  in  the  Air  Force  ADP  Experience  Handbook  (Pilot  Version)  and  posi¬ 
tion  the  center  arrow  of  the  Development  Slide  at  the  proposed  value  on  the  No.  of  Input  Transaction  Types  scale. 

3.  For  all  systems  bounded  by  the  Development  Slide,  enter  the  number  from  the  tolerance  band  in  the 
No.  of  Input  Transaction  Types  row  of  the  Ranking  Table  beneath  the  corresponding  system  name. 

4.  Repeat  steps  2  and  3  for  No.  of  Input  Data  Fields,  and  No.  of  Output  Formats. 

5.  Repeat  steps  2  and  3  for  No.  of  Data  Base  Record  Types  if  the  proposed  value  is  not  zero.  If  the  pro¬ 
posed  No.  of  Data  Base  Record  Types  is  zero,  enter  the  number  3  in  the  Data  Base  row  of  the  Rank¬ 
ing  Table  beneath  ADOBE,  MISSIM,  and  ORBIT. 

6.  Enter  the  Total  Rank  in  the  bottom  row  of  the  Ranking  Table.  Total  Rank  is  computed  by  adding  the 
numeric  entries  in  each  each  column  of  the  Ranking  Table. 

7.  The  system  with  the  largest  Total  Rank  is  the  most  relevant  system  in  developmental  aspects  to  the 
proposed  system.  Relevancy  of  other  systems  is  in  order  of  Total  Rank.  Systems  with  Total  Rank 
equal  to  or  greater  than  7  are  highly  relevant  to  the  proposed  automation.  Systems  with  Total  Rank 
less  than  7  but  greater  than  3  have  less  relevance,  but  may  still  be  used,  while  developmental  experi¬ 
ence  data  from  systems  with  Total  Rank  less  than  or  equal  to  3  should  not  be  used. 
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Formats 

Rank 

No.  of  Data 
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Use  of  the  Operations  Experience  Index 

The  operations  experience  index  is  used  to  retrieve  relevant  operations 
experience  from  the  system  descriptions.  Retrieval  is  based  on  the 
following  workload  descriptors: 

Char. /Mo.  of  Input  Volume 
Char.  /Mo.  of  Output  Volume 
Char,  in  Data  Base 

Proposed  values  of  these  workload  descriptors  must  be  known  for  the 
ADPS  under  evaluation.  The  type  of  operations  experience  and  prob¬ 
lems  retrieved  by  this  index  will  be  related  to  the  magnitude  of  the  op¬ 
erations.  Sections  of  the  system  descriptions  which  will  be  of  greatest 
interest  include: 

Operations 

Hardware 

Other  sections  of  interest  include: 


Organization 

Software 

File  Conversion 


Documentation 

Personnel 

Benefits 


Cost  Factors 
Description 


Procedure 

1.  Enter  the  proposed  values  for  Char.  /Mo.  of  Input  Volume,  Char.  /Mo.  of  Output  Volume,  and  Char, 
in  Data  Base  in  the  box  below  the  corresponding  scale. 

2.  Remove  the  index  card  from  the  pocket  in  the  Air  Force  ADP  Experience  Handbook  (Pilot  Version)  and  posi¬ 
tion  the  center  arrow  of  the  Operations  Slide  at  the  proposed  value  of  the  Char.  /Mo  of  Input  Volume  scale. 

3.  For  all  systems  bounded  by  the  Operations  Slide,  enter  the  number  from  the  tolerance  band  in  the 
Char.  /Mo.  of  Input  Volume  row  of  the  Ranking  Table  beneath  the  corresponding  system  name. 

4.  Repeat  steps  2  and  3  for  Char.  /Mo.  of  Output  Volume. 

5.  Repeat  steps  2  and  3  for  Char,  in  Data  Base,  if  the  proposed  value  is  not  zero.  If  the  proposed 
Char,  in  Data  Base  is  zero,  enter  the  number  3  in  the  Data  Base  row  of  the  Ranking  Table  beneath 
ADOBE,  M1SSIM,  and  ORBIT. 

6.  Enter  the  Total  Rank  in  the  bottom  row  of  the  Ranking  Table.  Total  Rank  is  computed  by  adding  the 
numeric  entries  in  each  column  of  the  Ranking  Table. 

7.  The  system  with  the  largest  Total  Rank  is  the  most  relevant  system  in  operational  aspects  to  the 
proposed  system.  Relevancy  of  other  systems  is  in  order  of  Total  Rank.  Systems  with  Total 
Rank  equal  to  or  greater  than  5  are  highly  relevant  to  the  proposed  system.  Systems  with  Total 
Rank  less  than  5  but  greater  than  2  have  less  relevance,  but  may  still  be  used,  while  operational 
experience  data  from  systems  with  Total  Rank  less  than  or  equal  to  2  should  not  be  used. 
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c. 


Functional  Area  Index 
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\  System 

Functional  \ 
Area  \ 

ADOBE 

AMPS 

DSWC 

GE/BSS 

GWC 

MAFR 

MILSTAMP 

MISSIM 

ORBIT 

u 

c 

a 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

Operations 

Supporting 

X 

X 

Research  and 
Development 

X 

X 

X 

Materiel 

Management 

X 

X 

X 

X 

Personnel/ 

Manpower 

X 

X 

Financial  and 
Accounting 

X 

X 

X 

X 

Weather 

X 

• 

T  ransportation 
Management 

X 

Miscellaneous 

X 

Use:  To  use  this  index,  find  the  row  of  the  Functional  Area  Index 
Table  with  the  same  functional  area  as  the  proposed  ADPS.  Systems  se¬ 
lected  with  the  same  functional  area  as  the  proposed  ADPS  are  designated 
by  an  "X"  in  this  row  under  the  system  acronym.  System  description 
sections  of  the  selected  systems  of  greatest  interest  are 

Function 

Description 

Other  system  description  sections  of  interest  are 

Application  Program  Development 

File  Conversion 

Personnel 

Application  Program  Maintenance 
Benefits 
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D.  Decentralized  Operations  Index 
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158 

\  System 

Number  oi\ 
Installations 

ADOBE 

AMPS 

DSWC 

GE/BSS 

GWC 

MAFR 

MILS  TAMP 

MISSIM 

ORBIT 

PDS 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

Single 

Installation 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

2  to  7 

Installations 

X 

X 

X 

8  to  100 
Installations 

X 

X 

X 

More  than  100 
Installations 

X 

X 

Use:  To  use  this  index,  find  the  row  of  the  Decentralized 
Operations  Index  Table  corresponding  to  the  number  of  operational 
installations  for  the  proposed  ADPS.  Systems  selected  with  the  number 
of  operational  installations  in  the  same  range  as  the  proposed  ADPS  are 
designated  by  an  nXn  in  this  row  under  the  system  acronym.  System 
description  sections  of  the  selected  systems  of  greatest  interest  are 

Location 

History 

Schedule 

Application  Program  Development 
Application  Program  Maintenance 

Other  system  description  sections  of  interest  are 

Organization 

Description 

Hardware 

Documentation 

Personnel 

Benefits 

Cost  F actors 
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E. 


Multiple  Application  Index 
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n.  System 

Number  01V 
Applications  \ 

ADOBE 

AMPS 

DSWC 

GE/BSS 

o 

£ 

o 

MAFR 

MILSTAMP 

MIS  SIM 

ORBIT 

1  1 
1  1 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

Single 

Application 

X 

X 

• 

J.  k 

X 

X 

X 

X 

2  to  10 
Applications 

X 

X 

X 

X 

More  than  10 
Applications 

X 

X 

X 

X 

X 

X 

X 

Use:  To  use  this  index,  find  the  row  of  1  he  Multiple  Applications 
Index  Table  corresponding  to  the  number  of  ap  >lications  at  an  installation 
for  the  proposed  ADPS.  Systems  selected  witl  the  number  of  applica¬ 
tions  in  the  same  range  as  the  proposed  ADPS  are  designated  by  an  MXn 
in  this  row  under  the  system  acronym.  The  s^  stem  description  section 
of  the  selected  systems  of  greatest  interest  is 

Operations 

Other  system  description  sections  of  interest  ;  re 

Organization 

Software 
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F. 


Programming  Language 
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n.  System 

Languages 'x 

ADOBE 

AMPS 

DSWC 

GE/BSS 

GWC 

MAFR 

MILSTAMP 

MISSIM 

ORBIT 

PDS 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

COBOL 

X 

X 

X 

X 

X 

FORTRAN 

X 

X 

X 

X 

X 

ALGOL 

X 

ALTAC 

X 

Autocoder 

X 

X 

X 

X 

GAP 

X 

FAP 

X 

X 

X 

ARGUS 

X 

RCA  Assembly 
Language 

X 

TAC 

X 

PAL 

X 

Machine 

Language 

X 

Use:  To  use  this  index,  find  the  row  of  Programming  Language 
Index  Table  with  the  same  programming  language  specified  for  the 
proposed  ADPS.  Systems  selected  with  the  same  programming  language 
as  the  proposed  ADPS  are  designated  by  an  "X11  in  this  row  under  the 
system  acronym.  The  system  description  sections  of  the  selected 
systems  of  greatest  interest  are 

Software 

Application  Program  Development 
Application  Program  Maintenance 

Other  system  description  sections  of  interest  are 

Description 

Hardware 

Personnel 

Benefits 
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G. 


Processing  Type  Index 
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n.  System 

Processing's 
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TCC 
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Real-Time 

Data 

Collection 

X 

X 

X 

X 

X 

On-Line 

Inquiry 

Processing 

X 

X 

X 

X 

X 

Batched  Under 
Executive 

Control 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Batched  With 

No  Executive 

X 

Use:  To  use  this  index,  find  the  row  of  :he  Processing  Type  Index 
Table  corresponding  to  the  processing  type  of  the  proposed  ADPS. 
Systems  selected  with  the  same  type  of  processing  as  the  proposed  ADPS 
are  designated  by  an  "X"  in  this  row  under  the  system  acronym.  System 
description  sections  of  the  selected  systems  o  '  greatest  interest  are 

Description 

Hardware 

Software 

Other  system  description  sections  of  interest  ire 
Workload 

Application  Program  Development 

Operations 

Cost  Factors 


201 


H. 


File  Conversion  Index 


Page  Number 

O' 

co 

vO 

Tt4 

CO 

m 

O 

vO 

v£> 

h- 

> — 1 

00 

00 

00 

m 

O' 

fM 

o 

rH 

O' 

O 

r— I 

sO 

• — t 

i — < 

on 

04 

rH 

O 

CO 

r-H 

r- 

CO 

r-H 

H 

r-H 

m 

<-H 

00 

m 

r-H 

\  System 

Type  of  FileN. 
Conversion  N. 
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sad 
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No.  File 
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X 

X 

X 
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Manual  to 

ADP  System 
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ADP  System 

X 

X 

ADP  System 
to  ADP  System 

X 

X 

X 

X 

X 

X 

X 

Use;  To  use  this  index,  find  the  row  of  the  File  Conversion  Index 
Table  corresponding  to  the  type  of  file  conversion  for  the  proposed  ADPS. 
Systems  selected  with  the  same  type  of  file  conversion  as  the  proposed 
ADPS  are  designated  by  an  "X"  in  this  row  under  the  system  acronym. 
The  system  description  section  of  the  selected  systems  of  greatest 
interest  is 


File  Conversion 

Other  system  description  sections  of  interest  are 

History 
Schedule 
Workload 
Hardware 
Cost  Factors 
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I.  Direct  Access  Storage  Index 
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Char. 

X 

Greater  than 

50M  Char. 

> 

X 

Use:  To  use  this  index,  find  the  row  of  tie  Direct  Access  Storage 
Index  Table  corresponding  to  the  amount  of  dir  set  access  storage  for  the 
proposed  ADPS.  Systems  selected  with  amoun  of  direct  access  storage 
in  the  same  range  as  the  proposed  ADPS  are  d<  signated  by  an  "X"  in  this 
row  under  the  system  acronym.  The  system  d  sscription  section  of  the 
selected  systems  of  greatest  interest  is 

Hardware 

Other  system  description  sections  of  interest  are 

Description 

Software 

Application  Program  Development 
Operations 

Application  Program  Maintenance 
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9,400 

11,422 

13,033 

14, 345 

15,319 

16,  151 

17, 060 

17, 640 

18,295 

19, 633 

31,315 

48,065 

60,390 

69,945 

72,430 

75,390 

85,825 

System 

Basic  Nv 

Computer 

Rental 

Page  Number 

X 

X 

ADOBE 

39 

AMPS 

46 

X 

DSWC 

53 

X 

GE/BSS 

60 

X 

X 

GWC 

67 

X 

W 

X 

MAFR 

74 

X 

X 

MILSTAMP 

81 

X 

X 

MISSIM 

88 

X 

X 

ORBIT 

95 

X 

PDS 

102 

X 

PDSO/MAC 

109 

X 

PDSO/MPC 
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Computer  Cost  Index 


J.  (Continued) 
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Use:  To  use  this  index,  find  the  row  of  tie  Computer  Cost  Index 
Table  with  closest  basic  monthly  rental  of  an  individual  computer  in  the 
proposed  ADPS.  Systems  selected  are  designs  ted  by  an  "X"  in  this  row 
under  the  system  acronym.  System  descriptio  is  sections  of  the  selected 
systems  of  greatest  interest  are 

Hardware 

Operations 

Other  system  description  sections  of  interest  ere 

History 
Schedule 
Workload 
Software 
Cost  Factors 
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Computer  Index 


K.  (Continued) 


Page  Number 

O' 

fO 

vO 

cO 

if) 

O 

vO 

r- 

vO 

00 

00 

00 

m  rq 
O  0 

•— 1 

O 

H 

vD 

rH 

ro 

rq 

O 

ro 

•H 

CO 

rH 

t-4 

in 

r-H 

00 

If) 

*“M 

System 

Computer 

ADOBE 

AMPS 

DSWC 

GE/BSS 

GWC 

MAFR 

MILSTAMP 

MISSIM 

E-i 

»-i 

PQ  in 
A 

O  A 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1051/BSS 

NCR  390 

X 

IBM  1620 

X 

Use;  To  use  this  index,  find  the  row  of  he  Computer  Index  Table 
with  the  same  computer  as  the  proposed  ADPS,  Systems  selected  using 
the  same  computer  as  the  proposed  ADPS  are  designated  by  an  "X"  in 
this  row  under  the  system  acronym.  System  c  escription  sections  of  the 
selected  systems  of  greatest  interest  are 

Hardware 

Operations 

Other  system  description  sections  of  interest  ire 

History 

Schedule 

Workload 

Software 

Application  Program  Development 
File  Conversion 

Application  Program  Maintenance 
Cost  Factors 
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Security  Index 
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Use:  To  use  this  index  find  the  row  of  the  Security  Index  Table 
with  the  same  security  classification  as  the  proposed  ADPS.  Systems 
selected  with  the  same  security  classification  as  the  proposed  ADPS  are 
designated  by  an  f,XM  in  this  row  under  the  system  acronym.  System 
description  sections  of  the  selected  systems  of  greatest  interest  are 

Organization 

Operations 

Other  system  description  sections  of  interest  are 

History 

Description 

Hardware 

Application  Program  Development 

File  Conversion 

Documentation 
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